Now I have a good amount of code broken by:
alias x = 5;
alias this = foo;
I don't expect all changes of a beta to be kept in a final
compiler version, but I think the removal of a syntax should be
announced (and discussed) in this newsgroup (if the removal of
such syntax was discussed in this newsgroup, then I have missed
it):
https://github.com/D-Programming-Language/dmd/issues/1413
Bye,
bearophile

I am also not aware of any discussion except for that.
For this particular case, I honestly also considered that killing
old syntax would not do much harm, but it is hard to estimate.
In general, until D has a stable and clear development policy, I
expect similar problems would happen over and over.

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

2013/2/10 kenji hara <k.hara.pg gmail.com>
Why I argue that the syntax `alias this = sym;` is wrong?
Because:
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, ...;` .

2a. I agree.
2b. I always assumed multiple alias would be introduced like
this...
alias this = sym1;
alias this = sym2;
... which also is "needed" if you use a "3rd party library mixin"
in your struct(which internally uses alias this), so even with
the ':' syntax it's anyway required to support being able to use
it multiple times:
alias this : sym1;
alias this : sym2;
So I don't think 2b speaks in favor of the new syntax.

... which also is "needed" if you use a "3rd party library mixin"
in your struct(which internally uses alias this), so even with
the ':' syntax it's anyway required to support being able to use
it multiple times:
alias this : sym1;
alias this : sym2;

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;

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'.

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.

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

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.

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.

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.