It's up to you whether you should learn it or not. The first point in the "why you should use lambdas" is very relevant to your concern about it not being seemingly useful for CP.

uou can always use regular methods which will even be much faster.

False, there are instances where lambdas are faster.

this blog is more for C++ developers than people who just use C++ for CP

What's the difference anyway? :) Anyway, it is not purely a C++ blog. It introduces a model of computation in the beginning that can make it much easier to think of things. Similarly, in some of the latter sections, I talk about some language-agnostic ways of doing programming, so it's not just about C++ developers.

Also, it is worth noting that every time there is a "new" feature, there is a non-trivial amount of pushback from the competitive programming community, saying "oh, this is not relevant for competitive programming, let's just stick to our global array pointer based adjacency list and manual for loops" and as a result they limit their own thinking process.

Rather than thinking in terms of abstract objects (which is what a lot of IMOers do, for instance, but not so many IOIers), programmers limit the way they think to the way they write their code. I've seen an interesting phenomenon happen with a lot of competitive programmers — if they don't have a decent amount of math experience, they are usually completely unable to reason about infinite sets, let alone real numbers. One reason is that they don't think about infinite sets of objects as much as the math people do, but the question is why do they avoid thinking of infinite sets? Surely you could just think of the indices of an array as being a half-infinite line, or circular arrays as being equivalence classes under the modulo operation (the latter had started gaining some momentum after circular array problems became common). But programmers don't do so, and this is mainly because they limit their thought process by their tools.

There are quite a lot of top competitive programmer who have been programming for a long time, but also have been flexible to change (some of their codes have been linked in the article). Not saying that this is the only way to grow as a competitive programmer, but it does not hurt to augment your knowledge graph from time to time, because unexpected connections pop up everywhere (for instance, IMO 2015 P6 was inspired from juggling, who could have guessed).

Ah yes, I somehow forgot to mention that, since I don't use global variables in the first place. I'll edit that in, thanks!

I think it's a matter of personal preference, but std::function has betrayed me multiple times in the past. I think you would really like the C++23 feature which would allow you to get rid of passing the lambda to itself (though the current state of things should remind you of Python member functions a bit). The y_combinator solution is a feasible solution for the meantime but it is definitely not the best solution either.

y_combinator also can allow you to write something like:

auto fact = [](auto fact, int n) -> int {
    if (n <= 1) return 1;
    return fact(n - 1); // notice fact and not self - naming hack
};
auto ans = y_combinator(fact)(10);

Another reason I moved to pure C++ lambda recursion is that std::function requires you to write the function signature twice, which is a bit weird in my opinion. (Unrelated, but the fact that we need to pass a lambda to itself (which can't be done in simply typed lambda calculus) for implementing recursion is because untyped lambda calculus is not Turing complete).

Thanks for the kind words! I'm glad that my templates had educational value as well.

I think the deduction guide should be fine, unless you run into any forwarding related issues. Though it would be better to replace your deduction guide with ycom(Func) -> ycom<std::decay_t<Func>> instead.

In the above code, you need to ensure that rather than *this, you pass std::ref(*this). This is because when you call ycom(f)(inputs) it copies ycom(f) by value whenever you're using *this, so any captures that you might have in f will seem to be "reset" just because you're using a new copy of f each time.

An example is in this code:

#include <iostream>

template <typename Func>
struct ycom {
    Func f;
    template <typename... T>
    auto operator()(T&&... args) {
        return f(*this, std::forward<T>(args)...);
    }
};
template <typename Func>
ycom(Func) -> ycom<Func>;

template <typename Func>
struct ycom_ref {
    Func f;
    template <typename... T>
    auto operator()(T&&... args) {
        return f(std::ref(*this), std::forward<T>(args)...);
    }
};
template <typename Func>
ycom_ref(Func) -> ycom_ref<Func>;

int main() {
    {
        auto f = [n_calls = 0](auto f, int x) mutable -> int {
            ++n_calls;
            std::cout << n_calls << '\n';
            if (x == 0) return 0;
            return n_calls + f(x - 1);
        };
        auto ans = ycom(f)(10);
        std::cout << "ans = " << ans << '\n';
    }
    {
        auto f = [n_calls = 0](auto f, int x) mutable -> int {
            ++n_calls;
            std::cout << n_calls << '\n';
            if (x == 0) return 0;
            return n_calls + f(x - 1);
        };
        auto ans = ycom_ref(f)(10);
        std::cout << "ans = " << ans << '\n';
    }
}

But you'll run into this issue — auto& f doesn't work instead of auto f if you use the std::ref version. This is because we are not making a copy, so the temporary ycom_ref(f) is trying to be passed as an lvalue, which should not work. This issue plagues the original version too, though, but you don't really need auto& f since std::ref makes a wrapper type emulating a reference.

Also, if you're returning a reference from a lambda, you will end up making a copy with auto — this is one of the very few places where decltype(auto) is required.

All in all, it is a wise decision to leave the y-combinator code untouched unless you want to really learn how stuff works under the hood.

const auto comp = [&](int a, int b) {return a > b; };
set<int, decltype(comp)> st(comp);

you need to pass the type of lambda to std::set type parameter, but the only way to do this is to assign lambda to some variable first.

After the edit: i don't actually know lol if it's possible, why not just assign it to variable first and pass in?

std::set<int, bool(*)(int, int)>> me(
    [&](int a, int b) {return a < b;}
);

this also works. I inserted 1million elements and removed them at random order:

~700ms multiset<int>
~700ms multiset<int, decltype(comp)> st(comp)
~775ms multiset<int, bool(*)(int, int)> st(comp)
~800ms multiset<int, function<bool(int, int)>> st(comp)

Either of the options will incur penalty, as they can't be inlined, but function pointer seems to be faster.

Edit: forgot to mention this will only work for lambdas without captures, which means code inside lambda can only access global variables.

This works:

template<typename T, typename U>
multiset<T, U> make_set(U comp) {
    return multiset<T, U>(comp);
}

    auto c = [&](int a, int b) {return a > b; };
    auto st = make_set<int>(c);

Deduction guide can't be added it seems (it needs to be defined right next to set definition), but function works.

In c++20, this seems to work, but only for lambdas without captures:

    multiset<int, decltype([](int a, int b) {
        return a > b;
    })> st;

I think this is because of this change and that C++ 20 lambda without closure does have a default constructor.

In C++20, you can do it with:

auto cmp = [](int x, int y) { return x < y; };
set<int, decltype(cmp)> s;

Or with an anonymous lambda:

set<int, decltype([](int x, int y) { return x < y; })> s;

However, the above do not work if you have a capture, you'll have to do this:

auto cmp = [&](int x, int y) { return a[x] < a[y]; };
set<int, decltype(cmp)> s(cmp);

This is because according to the C++ standard, the lambda's type doesn't have a default constructor if it has captures, and since the first one is basically set<int, decltype(cmp)> s(decltype(cmp){}), it only works with non-capturing lambdas.

Hi, I just wrote a blog regarding this here. As a bonus, it also talks about things like generalized hashing and PBDS.

Please give any suggestions to improve my lambda function

In cases like this, you should give a minimal reproducible example — a small code file where you remove as many things as possible while still keeping the error intact.

I've seen this error when using lambdas with VLAs (which are not legal C++ so you should not be using them either), are you using them by any chance?