https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #1 from Georgi D <georgid@outlook.com> ---
I discussed this is Andrey and Walter at D-Conf 2017 and the overall agreement is that it makes sense to change the mangling of voldemort types this way.

For the example above the mangled name changes like this:

- _D4test10__T3fooTiZ3fooFNaNbNiNfiZS4test10__T3fooTiZ3fooFiZ6Result + _D4test10__T3fooTiZ3fooFNaNbNiNfiZS4test10__T3fooTiZ6Result

--

https://issues.dlang.org/show_bug.cgi?id=17379

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de

--- Comment #2 from Rainer Schuetze <r.sagitario@gmx.de> ---
Is this meant as a special rule "if the symbol has only a single identifier, prepend the function name and signature"? This could work but only helps for some cases.

Otherwise it easily gets ambiguous and I'd rather see a special token for "unspecified return type" that could be demangled as "auto".

See https://github.com/dlang/dmd/pull/5855 for a more generic approach.

--

https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #3 from Georgi D <georgid@outlook.com> ---
(In reply to Rainer Schuetze from comment #2)
> Is this meant as a special rule "if the symbol has only a single identifier, prepend the function name and signature"? This could work but only helps for some cases.
> 

I am not sure what you mean by prepend the function name. The suggestion does not prepend the function name. Could you elaborate?

> Otherwise it easily gets ambiguous and I'd rather see a special token for "unspecified return type" that could be demangled as "auto".
> 
> See https://github.com/dlang/dmd/pull/5855 for a more generic approach.

This is not meant as a special case rule. It is a generic lowering of voldemort types in function templates to be as if defined outside of the function so they do not grow exponentially in size. It does not have a limit on the number of template arguments. It is also not ambiguous since the transformation is equivalent to explicitly writing out the template.

I am aware of https://github.com/dlang/dmd/pull/5855 and think it is a great idea but it is a compression of the symbol so if the original symbol is shorter then the compressed symbol is also going to be shorter. This suggestion tackles the problem of how the original symbol can be shorter.

--

https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #4 from Rainer Schuetze <r.sagitario@gmx.de> ---
> I am not sure what you mean by prepend the function name. The suggestion does not prepend the function name. Could you elaborate?

I meant that the demangler has to prepend the function name (including arguments to disambiguate overloads) to the identifier to print out the full name (if the demangled name is supposed not to show the transformation).

> This is not meant as a special case rule. ... It is also not ambiguous since the transformation is equivalent to explicitly writing out the template.

Consider similar structs defined elsewhere, e.g. in nested or chained functions:

template foo(T)
{
   static struct Result
   {
      int x;
   }

   auto fun(T t)
   {
      static struct Result
      {
         T t;
      }
      return Result(t);
   }

   auto foo(T t)
   {
      return fun(t);
   }
}

What is the mangling of the return type of foo?

--

https://issues.dlang.org/show_bug.cgi?id=17379

--- Comment #5 from Georgi D <georgid@outlook.com> ---
(In reply to Rainer Schuetze from comment #4)
> > I am not sure what you mean by prepend the function name. The suggestion does not prepend the function name. Could you elaborate?
> 
> I meant that the demangler has to prepend the function name (including arguments to disambiguate overloads) to the identifier to print out the full name (if the demangled name is supposed not to show the transformation).
> 
> > This is not meant as a special case rule. ... It is also not ambiguous since the transformation is equivalent to explicitly writing out the template.
> 
> Consider similar structs defined elsewhere, e.g. in nested or chained functions:
> 
> template foo(T)
> {
>    static struct Result
>    {
>       int x;
>    }
> 
>    auto fun(T t)
>    {
>       static struct Result
>       {
>          T t;
>       }
>       return Result(t);
>    }
> 
>    auto foo(T t)
>    {
>       return fun(t);
>    }
> }
> 
> What is the mangling of the return type of foo?

Yes, I did consider this case and in this sense the suggestion is for the case where there is only one entry in the template.

The position where I started this from is:

1) regardless of how good a compression is a shorter input will generate a
shorter output. Especially if the patterns are similar.
2) looking at the chain() method in std there is an equivalent transformation
which produces shorter symbol names by taking the voldemort type outside of the
method.
3) my first impulse was to create a pull request for phobos and make the
trasformation as a code change
4) following the path of 3) though would have meant removing all voldemort
types from phobos and in effect discouraging them in template code.
5) since I did not like 4) I considered the option of the compiler making the
transformation without the need of a code change.

The feature can be made more generic if we use a generated name for the voldemort types which are not supposed to be visible except by the compiler anyway.

--

https://issues.dlang.org/show_bug.cgi?id=17379

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |mangling
                 CC|                            |bugzilla@digitalmars.com

--

https://issues.dlang.org/show_bug.cgi?id=17379

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |schveiguy@yahoo.com
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=15831
         Resolution|---                         |WONTFIX

--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> ---
I think actually, we can close this, as Rainer's fix for issue (in the latest version of the compiler) mitigates the need for this.

There are also ambiguity problems when there are function overloads.

--

https://issues.dlang.org/show_bug.cgi?id=17379

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=17379

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Reopening, in case someone wishes to tackle this issue with the hairy problems it has.

The largest blocking issue to getting this to work is if you have 2 overloads of the same function template (this is completely made up, but something similar would cause problems):

auto foo(T)(T t, int x)
{
   static struct Result {T t; int x;}
   return Result(t, x);
}

auto foo(T)(T t, string x)
{
  static struct Result {T t; string x;}
  return Result(t, x);
}

If you refactor this, then the Result struct doesn't get properly mangled -- it only depends on the template itself. This will produce 2 identical manglings for the 2 functions.

Note that if you do actually do the refactoring here (move the Result outside the function), the current compiler simply doesn't redefine the Result struct -- it considers it fully defined in the first overload.

So a user would not refactor both, he would get errors on his compilation. But the compiler that was just adjusting the mangling would cause other problems.

--

https://issues.dlang.org/show_bug.cgi?id=17379

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pro.mathias.lang@gmail.com

--- Comment #8 from Mathias LANG <pro.mathias.lang@gmail.com> ---
I think we should close this. This issue title is about a solution rather than a problem. As you mentioned Steven, the underlying issue is mitigated by the backreference mangling, which is the "correct" solution IMO. Any lowering / rewrite invoke a risk of conflict / need for support in other tools (e.g. debugger), so it's just shifting the problem.

--