alias restriction??!

Paul Backus snarwin at
Sun Jul 19 17:06:14 UTC 2020

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; }
>>> 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:
> 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 =;

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 

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.


More information about the Digitalmars-d-learn mailing list