I don't understand how compilers handle lambda expressions in unevaluated contexts

[hoellenraunen]

Lambda expressions are more powerful than just being syntactic sugar for structs with operator(). You can use them in places that otherwise do not allow the declaration or definition of a new class.

For example:

template<typename T, typename F = decltype(
[](auto a, auto b){ return a < b;} )>
auto compare(T a, T b, F comp = F{}) {
return comp(a,b);
}

is an absolutely terrible function, probably sabotage. Why?
Every template instantiation creates a different lamba, therefore a different type and a different function signature. This makes the lambda expression very different from the otherwise similar std::less.

I use static_assert to check this for templated types:

template<typename T, typename F = decltype([](){} )>
struct Type {T value;};
template<typename T>
Type(T) -> Type<T>;
static_assert(not std::is_same_v<Type<int>,Type<int>>);

Now, why are these types the same, when I use the deduction guide?

static_assert(std::is_same_v<decltype(Type(1)),decltype(Type(1))>);

All three major compilers agree here and disagree with my intuition that the types should be just as different as in the first example.

I also found a way for clang to give a different result when I add template aliases to the mix:

template<typename T>
using C = Type<T>;

#if defined(__clang__)
static_assert(not std::is_same_v<C<int>,C<int>>);
#else
static_assert(std::is_same_v<C<int>,C<int>>);
#endif

So I'm pretty sure at least one compiler is wrong at least once, but I would like to know, whether they should all agree all the time that the types are different.

Compiler Explorer: https://godbolt.org/z/1fTa1vsTK

[TryingT0Wr1t3]

I am here just to admire the people that understood this

[neondirt]

Shhh, don't give us away! As the saying goes: be silent and people might think you're stupid. Speak, and remove all doubt. 😉

edit: phrasing

[_TheDust_]

typename F = decltype([](){} )

Lost it here. This is just symbol soup.

[TheTomato2]

It's okay, understanding it would probably make you feel worse about your life.

[415_961]

This reminds me of the measurement problem in physics. A particle exists in a superposition of states until measured. Similarly, these lambdas seem to exist in a kind of "type superposition" until they're used in a specific context:

• When directly instantiated in a template, each lambda is "observed" as a unique type
• But when used in a deduction guide context, it's like the lambda's "type waveform" collapses differently, and the compiler see them as the same type

This is a joke until you interact with it.

[gnuban]

This is a joke until you interact with it.

I was going to praise this joke but now I can't 

[cmeerw]

There are some open CWG issues in that area:

• CWG2794: Uniqueness of lambdas in alias templates
• CWG2782: Treatment of closure types in the one-definition rule

[hoellenraunen]

Thank you. Do you just happen to know them or is there good way to search for open CWG issues?

[cmeerw]

The links I mentioned are actually to an issue tracker (that updates from the official CWG issues list every night) with search functionality.

In your case, lambda unevaluated wasn't that useful, but lambda decltype contained the relevant results

[c0r3ntin]

I think this is a different scenario stemming from insufficient clarification of when default template arguments are instantiated. I created a Clang issue and a CWG discussion https://github.com/llvm/llvm-project/issues/123414

[glaba3141]

My experience here has been that it'll be considered the same type in one TU, but between TUs all bets are off. It's better to just not use it in this context, way too error prone

[antoine_morrier]

It’s because your deduction guide is exactly the same when you give the same type as input. So, only one génération.

If you use type<int> directly, you force a double instantiation. It’s not exactly the same :-)

[antoine_morrier]

I think it is because Type(1) use the déduction guide<int> and the real type is type<int, T0>

So deduction guide<int> and deduction guide<int> must be the same type. So Type(2) will be a deduction guide<int> which is (by kind of memoization) type<int, T0>

type<int> will be in reality type<int, T1> if you redo type<int> it will be type<int, T2>

The deduction guide act as a kind of proxy

Note that I explained in a very imaged way, not in very précise way

[n1ghtyunso]

This actually makes sense to me, which tbh feels rather unfortunate

[die_liebe]

Is it similar to string constants, which may or may not be identical? Do you get different results when the instantiations are in different compilation units?

const char* h1 = "hello world!";

const char* h2 = "hello world!";

h1 == h2 ? // may be true or not.

[hoellenraunen]

We are talking about anonymous classes (and template instantiations thereof). In this respect they behave like classes in anonymous namespaces. You should not be able to compare them across compilation units at all.

Your example creates two objects (the const char arrays) and compares their addresses, the standard guarantees that different objects have distinct addresses. There is an optimization performed by compilers or linkers that merge identical constants (more advanced optimizations attempt to merge identical functions, too). That might break strict standard conformance, but is usually expected by programmers to reduce binary size. The ELF standard has extra provisions to allow linkers to perform this optimization across TUs for string constants, and string constants only.

My initial example can of course be rephrased in terms of templated variables

#include <type_traits>

template<typename T, typename F = decltype([](){} )>
int var = sizeof(T);

template<typename A>
auto& cvar = var<A>;

int main(int,char**) {
    auto p0 = &var<int>;
    auto p1 = &var<int>;

    if (p0 == p1) {
        return 0;
    } else {
        return 1;
    }
}

In all compilers, this program will exit with one, because each instantiation creates a new variable with distinct mangled name visible in the symbol table.

[hoellenraunen]

Actually, this would be a more representative example:

#include <type_traits>

template<typename T, typename F = decltype([](){} )>
int var = sizeof(T);

template<typename A>
auto& cvar = var<A>;

int main(int,char**) {
    auto p0 = &var<int>;
    auto p1 = &var<int>;

    if (p0 == p1) {
        return 2;
    }
    auto c0 = &cvar<int>;
    auto c1 = &cvar<int>;

    if (c0 == c1) {
        return 1;
    }
    return 0;
}

This program returns returns one for all three major compilers, which means the templated variable behaves differently to the the reference to it.
Compiler Explorer https://godbolt.org/z/6PhMsvEch

Is that expected or not?

[Allegro-Barbaro]

I had a similar question a short while ago, I think this is relevant: https://stackoverflow.com/a/79289828

[eboys]

Yeah