Mangling late-specified return types/decltype

[Doug Gregor]

On Fri, Sep 5, 2008 at 1:27 PM, Jason Merrill <jason at redhat.com> wrote:
> Consider
>
> template<class T, class U>
> auto add(T t, U u) -> decltype (t+u);
>
> There is currently no way to mangle "t" in the ABI.  Currently I'm dealing
> this by replacing "t" in the return type with *(T*)0, but that seems
> inelegant (and unnecessarily long).
>
> I think we don't want to mangle it as a reference to a function parameter,
> but rather as a placeholder expression with the type of the parameter.
>  Perhaps sT <type>?

This seems like an odd choice to me. Is it okay that these two will
have the same mangling:

  template<typename T> void f(T x, T y) -> decltype(x + y) { } // #1
  template<typename T> void f(T x, T y) -> decltype(x + x) { } // #2

while these two, which also have the same return type, have different manglings?

  template<typename T> void f(T&& x, T& y) -> decltype(x + y) { } // #3
  template<typename T> void f(T&& x, T& y) -> decltype(x + x) { } // #4

The return types are the same because parameters whose type is an
rvalue reference are treated as lvalues, so "x" and "y" behave the
same way from the point of view of the type system. However, we're
mangling x and y differently because they have different declared
types.

It seems like we either want #1 and #2 to have different manglings (by
making references to function parameters like we do with template
parameters) or we want #3 and #4 to have the same mangling (e.g., by
using the type of the expression with an lvalue or rvalue marker).

> Incidentally, the ABI still lacks any way to mangle T() or myfn(args).
>
> We could mangle T() using 'v' for the operand.
>
> We could mangle myfn(args) as a binary expression using the encoding for
> operator() where the first operand is the name of the function and the
> second operand is the list of args wrapped in some delimiters.

These seem fine to me.

  - Doug