alias restriction??!

[Paul Backus]

On Sunday, 19 July 2020 at 16:00:28 UTC, Basile B. wrote:
> On Sunday, 19 July 2020 at 15:00:59 UTC, Paul Backus wrote:
>> On Sunday, 19 July 2020 at 12:42:47 UTC, Carl Sturtivant wrote:
>>> On Sunday, 19 July 2020 at 12:08:07 UTC, Paul Backus wrote:
>>>>
>>>> Easiest workaround:
>>>>
>>>> ref inout(long) Second() inout { return second.one; }
>>>
>>> Was trying to avoid this for performance reasons. In fact 
>>> what are the performance implications of this sort of thing 
>>> with current implementations? --- relative to using a simple 
>>> offset.
>>
>> Almost certainly no difference at all. Even DMD can inline 
>> this function:
>>
>> https://d.godbolt.org/z/7ve6M8
>
> The alias proposal matches to the "code fast" moto. When you do 
> object composition with several level of nesting this would be 
> a time saver.

It replaces something that's already a one-liner with a slightly 
shorter one-liner. Color me unimpressed.

Also, letting aliases refer to expressions essentially allows AST 
macros in through the back door. Consider the following example:

template counter()
{
     struct Counter
     {
         static size_t count;
         size_t next() { return count++; }
     }

     alias counter = Counter.init.next;
}

void main()
{
     import std.stdio: writeln;

     writeln(counter!()); // 0
     writeln(counter!()); // 1
     writeln(counter!()); // 2
}

This program compiles, runs, and prints the indicated output 
using the version of dmd built from the member-alias pull request 
[1].

Personally, I'm in favor of AST macros, but if we're going to add 
them to D, I think we should do it intentionally, rather than by 
accident, and there should be a DIP.

[1] https://github.com/dlang/dmd/pull/11273