On Friday, 22 February 2013 at 17:38:49 UTC, Ali Çehreli wrote:

> I have a feeling that there must have been some newsgroup discussions as well but unfortunately I must have been busy with other things at the time. Not all of us read github.
>
> Ali

You should not have to, and this is a problem with D that somehow needs to be solved. For example, there should be a versioned language specification that documents all changes to the language that can be mapped to any given compiler implementation. I don't know how we'll ever get the language properly documented and revised, but it's needed badly.

Now I'm left wondering if 2.062 allows multiple alias this or not, so to find out I have to read through git and newsgroups, or try it out, or ask ...

--rt

On Friday, 22 February 2013 at 17:38:49 UTC, Ali Çehreli wrote:
> I appreciate everybody's contributions to D but that is not an intention, that is a change to dmd that caused a regression. A syntax that used to work in the previous version simply stopped working in 2.062. That is the definition of a regression. Normally, regressions are fixed as quickly as possible.
>
> I have a feeling that there must have been some newsgroup discussions as well but unfortunately I must have been busy with other things at the time. Not all of us read github.
>

I also have to say that I fail to see the logic.

Breaking changes to fix long standing languages issue are often refused because it is bad to break code, but it is allowed ot break syntax that causes no issue.

On 02/22/2013 09:27 AM, Ali Çehreli wrote:
> On 02/22/2013 09:08 AM, Ali Çehreli wrote:
>> On 02/22/2013 06:55 AM, bearophile wrote:
>> > Martin:
>> >
>> >> Was something changed intentionally or is this a bug?
>> >
>> > It was changed intentionally, but only for alias this. That syntax is
>> > allowed still for other aliases.
>>
>> It is a regression at best
>
> Posted:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9569
>
> Ali

bearophile has added this link to the bug discussion:

  http://forum.dlang.org/thread/evldispcxhyarckmkycg@forum.dlang.org

It is ironic that the 2.061 'alias this' syntax got killed because it broke 2.060 programs. However, the 2.061 'alias this' syntax will not be brought back even though its demise have broken 2.061 programs!

Oh well... Time to go fix the 'alias this' chapter again.

Ali

Am Fri, 22 Feb 2013 09:38:48 -0800
schrieb Ali Çehreli <acehreli@yahoo.com>:

> I appreciate everybody's contributions to D but that is not an intention, that is a change to dmd that caused a regression. A syntax that used to work in the previous version simply stopped working in 2.062. That is the definition of a regression. Normally, regressions are fixed as quickly as possible.
> 
> I have a feeling that there must have been some newsgroup discussions as well but unfortunately I must have been busy with other things at the time. Not all of us read github.
> 
> Ali

No, this was not meant to be a feature. It slipped in and
people started using it. It's like being able to break "scope"
parameters by storing aliases to what's inside of them. If you
rely on that now and it is fixed in a future version, it's not
a regression.
That said I started using "alias this = ..." as well and was
surprised it was removed, but noticed it in time as a DFeed
line on IRC.

-- 
Marco

On 2/22/13, Marco Leise <Marco.Leise@gmx.de> wrote:
> That said I started using "alias this = ..." as well and was surprised it was removed, but noticed it in time as a DFeed line on IRC.

It will be documented in the changelog once https://github.com/D-Programming-Language/d-programming-language.org/pull/284 is pulled.

>>>>>> Was something changed intentionally or is this a bug?
>>>>>
>>>>> It was changed intentionally, but only for alias this. That syntax is allowed still for other aliases.
>>>>>
>>>>> Bye,
>>>>> bearophile
>>>>
>>>> I see, thanks. What was the reason for not allowing alias this = identifier?
>>>
>>> Requiring lookahead when parsing.
>>
>> Alright, thanks!
>
> Just to be clear : that was sarcastic, requiring lookahead when parsing is a drawback.
>
> The idea is that alias and alias this are 2 different beasts. For instance you can have multiple alias this when you can only have one name per identifier.
>
> It was wanted to distinguish the 2 with 2 different syntaxes.

alias, alias this, "alias not for this" and "maybe not alias" requested.
Three changes in three versions, what the next?

Yes, it's small changes, but really annoying.

What the problem for multiple "alias this"?

alias this = i;
alias this = y;

and

alias i this;
alias y this;

+1 for first sample: all aliases in one way.

On 02/22/2013 03:51 PM, Martin wrote:
> struct Test
> {
>      int i;
>      alias this = i;
> }
>
> Worked fine in 2.061 but in 2.062 I get the errors
> "Error: no identifier for declarator this" and "Error: alias cannot have
> initializer".
>
> Was something changed intentionally or is this a bug?

It is (embarrassingly!) intentional.

I consider the change bad and the reasoning behind it extraordinarily bad. alias this is by far whacky enough.

On 02/22/2013 07:30 PM, Marco Leise wrote:
> Am Fri, 22 Feb 2013 09:38:48 -0800
> schrieb Ali Çehreli <acehreli@yahoo.com>:
>
>> I appreciate everybody's contributions to D but that is not an
>> intention, that is a change to dmd that caused a regression. A syntax
>> that used to work in the previous version simply stopped working in
>> 2.062. That is the definition of a regression. Normally, regressions are
>> fixed as quickly as possible.
>>
>> I have a feeling that there must have been some newsgroup discussions as
>> well but unfortunately I must have been busy with other things at the
>> time. Not all of us read github.
>>
>> Ali
>
> No, this was not meant to be a feature. It slipped in and
> people started using it.  It's like being able to break "scope"
> parameters by storing aliases to what's inside of them.

It is nothing like that.

See https://github.com/D-Programming-Language/dmd/pull/1187/files#L0R2780

It is explicitly handled in the code. Looking at the code for two seconds reveals that this syntax is being added.

> If you rely on that now and it is fixed in a future version, it's not
> a regression.

Maybe it is not a regression. In any case it is a breaking language change. (also holds for the scope stuff; there is no spec for it.)

> That said I started using "alias this = ..." as well and was
> surprised it was removed, but noticed it in time as a DFeed
> line on IRC.
>

There is no justification for this.

I guess the main issue is that alias blah this; shouldn't have made it into the grammar in the first place. But this was obviously done in order to establish a broken analogy to the other uses of alias. Either alias this=blah; must be kept or the alias this syntax should be deprecated in favour of a specially named member function.

> There is no justification for this.
>
> I guess the main issue is that alias blah this; shouldn't have made it into the grammar in the first place. But this was obviously done in order to establish a broken analogy to the other uses of alias. Either alias this=blah; must be kept or the alias this syntax should be deprecated in favour of a specially named member function.

+1

On Friday, 22 February 2013 at 21:23:04 UTC, Timon Gehr wrote:
> [snip].. or the alias this syntax should be deprecated in favour of a specially named member function.

pseudonym foo;