On 5/19/16 6:17 PM, Walter Bright wrote:
> On 5/19/2016 8:39 AM, Steven Schveighoffer wrote:
>>> template(T) foo if (someConstraints)
>>> {
>>>     struct Result
>>>     {
>>>        T t;
>>>     }
>>>
>>>     auto foo(T t)
>>>     {
>>>        return Result(t);
>>>     }
>>> }
>>
>> This solution works awesomely, actually. It even produces smaller code
>> than
>> moving the struct completely outside.
>>
>> I'm going to use this mechanism in iopipe to get my voldemorts back :)
>
>
> Consider using a 'static struct'. A non-static struct will include a
> hidden member that points to the stack frame of foo(), i.e. "produces
> smaller code".

Yes, I did use static in my actual code. In fact, I found a bug because of this (one of my voldemort functions was allocating a closure because I had thought I was using a member but was actually using a function parameter).

But this doesn't fix the symbol size problem. The other mechanism does.

-Steve

On 5/22/16 5:42 PM, Andrei Alexandrescu wrote:
> On 05/21/2016 03:13 PM, Kagamin wrote:
>> On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu wrote:
>>> He said that that won't happen any longer, the growth was because of
>>> the return type. Is that correct?
>>
>> https://issues.dlang.org/show_bug.cgi?id=15831#c4
>> Looks like growth is due to the fact that the voldemort type is in the
>> scope of a function and function is fun!(T).fun(T) - hence each level
>> multiplies by 2. And return type is not part of the mangled name already
>> - that would cause circular dependency, you would need the voldemort
>> type mangling to generate it.
>
> Just to make sure I understand: do you agree or disagree that there's no
> more exponential growth if we encode "auto return" in the mangling? Thx!
> -- Andrei

Not sure if someone has definitively answered before, but no, this does not. I think this would shrink the growth from 3^n to 2^n.

The exponential growth happens because of the repeating of the template types.

If you look at the example in the bug report, there is no return types anywhere. They exist in the mangled names, but are not relevant to the FQN or symbol resolution. The return type only plays a factor for preventing linking against other files that expect a certain return type. In fact, this may be a reason to NOT shortcut the return mangle (if you had compiled against foo one day, and foo's internal voldemort type changes the next, it would still link, even though the type may have changed).

Indeed, D does not overload based on return type ever.

-Steve

On 5/23/16 3:03 PM, Steven Schveighoffer wrote:

> In fact, this may be a reason to NOT shortcut the return mangle
> (if you had compiled against foo one day, and foo's internal voldemort
> type changes the next, it would still link, even though the type may
> have changed).

Actually, this is not true. It will only fail to link if the name of the internal type changes, or you return some other type :(

-Steve

On 5/23/16 3:03 PM, Steven Schveighoffer wrote:
> On 5/22/16 5:42 PM, Andrei Alexandrescu wrote:
>> On 05/21/2016 03:13 PM, Kagamin wrote:
>>> On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu wrote:
>>>> He said that that won't happen any longer, the growth was because of
>>>> the return type. Is that correct?
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=15831#c4
>>> Looks like growth is due to the fact that the voldemort type is in the
>>> scope of a function and function is fun!(T).fun(T) - hence each level
>>> multiplies by 2. And return type is not part of the mangled name already
>>> - that would cause circular dependency, you would need the voldemort
>>> type mangling to generate it.
>>
>> Just to make sure I understand: do you agree or disagree that there's no
>> more exponential growth if we encode "auto return" in the mangling? Thx!
>> -- Andrei
>
> Not sure if someone has definitively answered before, but no, this does
> not. I think this would shrink the growth from 3^n to 2^n.
>

To clarify, I think this is still a good idea, but only if the type is defined internally (no reason to repeat the entire function signature of the function you are defining). But if you specify auto return and return int, it should still be mangled as returning int.

-Steve

On 5/23/2016 12:03 PM, Steven Schveighoffer wrote:
> Indeed, D does not overload based on return type ever.

It does factor into type matching when a function pointer is used, for example.

On 5/23/16 4:25 PM, Walter Bright wrote:
> On 5/23/2016 12:03 PM, Steven Schveighoffer wrote:
>> Indeed, D does not overload based on return type ever.
>
> It does factor into type matching when a function pointer is used, for
> example.
>

Yes, that may be the only time return type is factored in, but practically speaking, a function overload set that overloads solely on return type is not directly callable (you will get ambiguity error), so there is little point to create such a situation.

-Steve