On 11/02/2013 10:46, Stewart Gordon wrote:
> On 10/02/2013 13:13, bearophile wrote:
>> Now I have a good amount of code broken by:
>>
>> alias x = 5;
>> alias this = foo;
>
> Was this ever documented?  How many people ever knew this syntax
> existed?  Not me....

The 2.061 changelog has a 'new/changed features' link to bugzilla items, where there's an item 'alias should have assignment syntax'.

There are two issues with this approach:

1. Alias assignment syntax is (probably) a more interesting change to many D users than quite a few of the other new/changed items listed. It is buried amongst some less interesting items.

2. Being a bugzilla item title it doesn't contain syntax examples, which is what a changelog reader would like to see.

The new deprecated switches item did get a paragraph in the changelog, but other significant changes did not.

On Sunday, 10 February 2013 at 14:42:50 UTC, kenji hara wrote:
> Why I argue that the syntax `alias this = sym;` is wrong? Because:
>
> 1. A normal alias declaration (creating aliased name for existing symbol)
> and alias this feature
> (making a *subtyped* struct through implicit access to its field) are
> entirely different and has distinct semantics.
> They merely share a keyword 'alias'.

I think alias this works like alias. Shouldn't subtyped object support casting to any its type? Contrarily alias this simply redirects access like alias and has nothing to do with types, so it's pretty valid to see it as an alias.

On 2013-35-10 17:02, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> I've argued that it should be rare that someone uses multiple
> subtyping, so I don't see the need to introduce more syntax into the
> language when they can simply do this for the special occasion when
> they need it:
>
> alias this = this;
> alias this = bar;

The point of this change is not really to allow multiple subtyping,
but to indicate that alias this is different from other aliases. It is
a Good Thing(tm).

-- 
Simen

> Why I argue that the syntax `alias this = sym;` is wrong? Because:
>
> 1. A normal alias declaration (creating aliased name for existing symbol)
> and alias this feature
> (making a *subtyped* struct through implicit access to its field) are
> entirely different and has distinct semantics.
> They merely share a keyword 'alias'.
>
> 2. Instead, we can have much more consistent, useful, and scalable syntax.
> At the same time, I proposed a new syntax `alias this : ident;` for alias
> this feature.
> https://github.com/D-Programming-Language/d-programming-language.org/pull/200
>
> struct S {
>     int value;
>     alias this : value;   // proposed syntax
> }
>
> Benefits of the proposed syntax are:
> 2a. It is consistent with class inheritance syntax `class C : B {}`.
> 2b. It is scalable for multiple alias this feature, as like `alias this
> : sym1, sym2, ...;` .
>
> If D community highly require the syntax `alias this = sym`, I'll agree to
> adding it again.
> But for that, we should discuss about its cost and benefit.
>
> Sorry for my poor writing.
> Regards.
>
> Kenji Hara

http://forum.dlang.org/thread/aaflopktcjmljxdnoizj@forum.dlang.org
http://d.puremagic.com/issues/show_bug.cgi?id=9569

On 02/10/2013 03:42 PM, kenji hara wrote:
> 2013/2/10 kenji hara <k.hara.pg@gmail.com <mailto:k.hara.pg@gmail.com>>
>
>
>     I opened the pull request #1413 in the beta term for 2.061, but it
>     had _accidentally_ released without deeply discussion.
>     https://github.com/D-Programming-Language/dmd/pull/1413
>
>     I think and believe that we MUST reset things.
>
>
> Why I argue that the syntax `alias this = sym;` is wrong?

Do you have any arguments that do not also apply to

alias sym this;

?

> Because:
>
> 1. A normal alias declaration (creating aliased name for existing
> symbol) and alias this feature
> (making a *subtyped*  struct through implicit access to its field)

Actually that is not what subtyping means.

> are entirely different and has distinct semantics.

Yet they already deliberately share the same piece of syntax. The problems cannot be attributed to the alias assignment syntax addition.

> They merely share a keyword 'alias'.
>

No, they share the entire declaration syntax.

alias foo this;
alias foo that;

> 2. Instead, we can have much more consistent,

alias foo that; // ok
alias foo this; // ok
alias that=foo; // ok
alias this=foo; // uh...

> useful,

All are of the same usefulness.

> and scalable syntax.
> At the same time, I proposed a new syntax `alias this : ident;` for
> alias this feature.

Yes, what is the point? Why would a new syntax that's deliberately inconsistent with alias syntax require an 'alias' keyword? It is not an alias. The other special aggregate members are just specially named symbols.

> https://github.com/D-Programming-Language/d-programming-language.org/pull/200
>
> struct S {
>      int value;
>      alias this : value;   // proposed syntax
> }
>
> Benefits of the proposed syntax are:
> 2a. It is consistent with class inheritance syntax `class C : B {}`.

It's hardly consistent, and you were opposed to entirely different constructs having similar syntax above!

> 2b. It is scalable for multiple alias this feature, as like `alias this
> : sym1, sym2, ...;` .

TDPL says:

alias sym1 this;
alias sym2 this;
...


>
> If D community highly require the syntax `alias this = sym`, I'll agree
> to adding it again.
> But for that, we should discuss about its cost and benefit.
> ...

The syntax to access the alias this functionality is quite whacky. Applying a partial fix without going all the way just increases confusion.