[cxx-abi-dev] Mangling sizeof

[Doug Gregor]

On Sun, Mar 8, 2009 at 12:32 PM, John H. Spicer <jhs at edg.com> wrote:
>
> On Mar 8, 2009, at 1:06 PM, Doug Gregor wrote:
>
>
> And finally,
>
> * lambda
>
> Completely mangling lamba expressions in sizeof/decltype/alignof would mean
>
> having to mangle arbitrary statements as well, which seems rather a bridge
>
> too far.
>
> Yes, it does. I suggest that we consider all lambda expressions with
> the same parameter type lists and return type (if provided) to be
> "functionally equivalent". That way, we need only mangle the lambda's
> call signature and not its body.
>
> And, although it doesn't have any direct impact on the ABI, I think we
> also need to say that failures substituting into the body of a lambda
> are not substitution failures.
>
> I'm not sure what you mean by this.    Do you mean you don't substitute into
> a lambda body and if you select the function you get a hard error?

I mean that, if substitution fails, it's a hard error rather than a
substitution failure from which the compiler must recover.

> Is there any reason not to just say that doing substitution on an lambda
> expression results in a substitution failure?

Implementation cost, for one. We currently have to be able to recover
from a substitution failure in any expression or type. If we say that
substitution into a lambda cannot result in a hard error, it means
that we have to be able to recover from substitution failures in any
statement that occurs in the lambda.

Also, Jaakko and I discussed this for a bit, and we can only find
"evil" uses for this feature [*]. In part, because of:

> In other words, something
> like:
> template <class T> void f(T, decltype([](T t){ /* something */ }* t){}
> would not be callable?

It's not going to be callable anyway, since you won't be able to
create an object with the same type as the lambda. In fact, it looks
like the only way to meaningfully use a lambda within the signature of
a template involves sizeof(), and one could question whether such a
thing is really meaningful.

That would change slightly if the unified function syntax proposal
gets accepted, because one could then write, e.g.,

  template<typename T>
    [] f(T) -> auto { return [](T t, T t) { return t + t; } }

There, we actually have a useful formulation where a lambda's type
shows up in the signature.

  - Doug

[*] Evil use #1: replicate the body of the template within the lambda,
so that it's a SFINAE case if the template definition would fail to
compile.