www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What happened to the alias this = identifier syntax in 2.062?

reply "Martin" <martinbbjerregaard gmail.com> writes:
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?
Feb 22 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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. Bye, bearophile
Feb 22 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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 because it is nowhere to be found in the changelog, at least not without clicking every single item in those lists. Ali
Feb 22 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Feb 22 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Feb 22 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 02/22/2013 09:28 AM, kenji hara wrote:
 2013/2/23 Ali Çehreli<acehreli yahoo.com>

 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 because it is nowhere to be found in the changelog, at least not without clicking every single item in those


 That is intended change.
 https://github.com/D-Programming-Language/dmd/issues/1413
 

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
Feb 22 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Feb 22 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/23/2013 12:10 AM, Joshua Niehus wrote:
 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;

auto opPseudonym() { ... } alias opPseudonym=foo;
Feb 22 2013
prev sibling next sibling parent "Martin" <martinbbjerregaard gmail.com> writes:
On Friday, 22 February 2013 at 14:55:19 UTC, 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. Bye, bearophile

I see, thanks. What was the reason for not allowing alias this = identifier?
Feb 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 February 2013 at 14:58:02 UTC, Martin wrote:
 On Friday, 22 February 2013 at 14:55:19 UTC, 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. Bye, bearophile

I see, thanks. What was the reason for not allowing alias this = identifier?

Requiring lookahead when parsing.
Feb 22 2013
prev sibling next sibling parent "Martin" <martinbbjerregaard gmail.com> writes:
On Friday, 22 February 2013 at 15:07:29 UTC, deadalnix wrote:
 On Friday, 22 February 2013 at 14:58:02 UTC, Martin wrote:
 On Friday, 22 February 2013 at 14:55:19 UTC, 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. Bye, bearophile

I see, thanks. What was the reason for not allowing alias this = identifier?

Requiring lookahead when parsing.

Alright, thanks!
Feb 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 February 2013 at 15:31:43 UTC, Martin wrote:
 On Friday, 22 February 2013 at 15:07:29 UTC, deadalnix wrote:
 On Friday, 22 February 2013 at 14:58:02 UTC, Martin wrote:
 On Friday, 22 February 2013 at 14:55:19 UTC, 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. 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.
Feb 22 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--047d7bf10a8684ffb704d6538420
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/2/23 Ali =C3=87ehreli <acehreli yahoo.com>

 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 because it is nowhere to be found in the changelog, at least not without clicking every single item in those lists=

That is intended change. https://github.com/D-Programming-Language/dmd/issues/1413 https://github.com/D-Programming-Language/d-programming-language.org/pull/2= 24 Kenji Hara --047d7bf10a8684ffb704d6538420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/23 Ali =C3=87ehreli <span dir=3D"ltr">&lt;<a href= =3D"mailto:acehreli yahoo.com" target=3D"_blank">acehreli yahoo.com</a>&gt;= </span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width= :1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef= t:1ex"> <div class=3D""><div class=3D"h5">On 02/22/2013 06:55 AM, bearophile wrote:= <br> &gt; Martin:<br> &gt;<br> &gt;&gt; Was something changed intentionally or is this a bug?<br> &gt;<br> &gt; It was changed intentionally, but only for alias this. That syntax is<= br> &gt; allowed still for other aliases.<br> <br></div></div> It is a regression at best because it is nowhere to be found in the changel= og, at least not without clicking every single item in those lists.</blockq= uote><div><br></div><div style>That is intended change.</div><div style> <a href=3D"https://github.com/D-Programming-Language/dmd/issues/1413">https= ://github.com/D-Programming-Language/dmd/issues/1413</a></div><div style><a= href=3D"https://github.com/D-Programming-Language/d-programming-language.o= rg/pull/224">https://github.com/D-Programming-Language/d-programming-langua= ge.org/pull/224</a></div> <div style><br></div><div style>Kenji Hara=C2=A0</div></div></div></div> --047d7bf10a8684ffb704d6538420--
Feb 22 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Feb 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 22 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 22 Feb 2013 09:38:48 -0800
schrieb Ali =C3=87ehreli <acehreli yahoo.com>:

 I appreciate everybody's contributions to D but that is not an=20
 intention, that is a change to dmd that caused a regression. A syntax=20
 that used to work in the previous version simply stopped working in=20
 2.062. That is the definition of a regression. Normally, regressions are=

 fixed as quickly as possible.
=20
 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=20
 time. Not all of us read github.
=20
 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 =3D ..." as well and was surprised it was removed, but noticed it in time as a DFeed line on IRC. --=20 Marco
Feb 22 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Feb 22 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
 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.
Feb 22 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Feb 22 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
 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
Feb 22 2013
prev sibling next sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
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;
Feb 22 2013
prev sibling next sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
On Friday, 22 February 2013 at 23:20:55 UTC, Timon Gehr wrote:
 auto opPseudonym() { ... }

 alias opPseudonym=foo;

Isn't that creating multiple functions for the same thing? <shamelessly copies Ali's example> struct Fraction { long numerator; long denominator; double value() const property { return cast(double)numerator / denominator; } alias this = value; } as opposed to: struct Fraction { long numerator; long denominator; double value() const property { return cast(double)numerator / denominator; } pseudonym value; // in the year 2000... pseudonym value, value2, value3; }
Feb 22 2013
prev sibling next sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
didn't fully formulate that thought:

above examples vs. the following

struct Fraction
{
     long numerator;
     long denominator;

     double value() const  property
     {
         return cast(double)numerator / denominator;
     }

     auto opPseudonym() { /* points to value() ? */ }
     alias opPsuedonym=value;  // ??
}
Feb 22 2013
prev sibling next sibling parent "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
On Friday, 22 February 2013 at 21:23:04 UTC, Timon Gehr wrote:
 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.

I believe the alias syntax was based on typedef, which was inherited from C, and has now been removed from D; so the justification was there in the past, but now absent which is why the change is happening now. As far as replacing 'alias...this' with a member function, that's precisely how it *used* to be done with opDot(), but it suffered from overhead. I had thought, at the time 'alias...this' was first introduced, that the two were meant to live side by side, but then the realization came that one could actually achieve opDot's purpose with clever use of 'alias...this' so the latter fell out of favor. Alas.
Feb 23 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 23, 2013 09:47:54 Chris Nicholson-Sauls wrote:
 On Friday, 22 February 2013 at 21:23:04 UTC, Timon Gehr wrote:
 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.

I believe the alias syntax was based on typedef, which was inherited from C, and has now been removed from D; so the justification was there in the past, but now absent which is why the change is happening now.

alias bar = foo; was added simply because a number of folks didn't like alias foo bar; Both will continue to be supported. The only issue here is the fact that when alias bar = foo; was added, alias this = blah; was also added, but it was suddenly removed with the most recent release. Whether it's a good idea to disallow it or not, I don't know, but it broke people's code when it was removed, because some folks had started to use it - hence the complaints. alias bar = foo; is unaffected however.
 As far as replacing 'alias...this' with a member function, that's
 precisely how it *used* to be done with opDot(), but it suffered
 from overhead. I had thought, at the time 'alias...this' was
 first introduced, that the two were meant to live side by side,
 but then the realization came that one could actually achieve
 opDot's purpose with clever use of 'alias...this' so the latter
 fell out of favor.  Alas.

alias this is supposed to completely replace opDot, and it's far more flexible than opDot, so there's really no reason to have opDot anymore. For whatever reason, opDot doesn't appear to have been actually deprecated yet, but it's supposed to be getting the axe at some point. - Jonathan M Davis
Feb 23 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 23 February 2013 at 09:24:20 UTC, Jonathan M Davis 
wrote:
 alias this is supposed to completely replace opDot, and it's 
 far more flexible
 than opDot, so there's really no reason to have opDot anymore. 
 For whatever
 reason, opDot doesn't appear to have been actually deprecated 
 yet, but it's
 supposed to be getting the axe at some point.

It come with quite a lot of problems solved in an implementation defined way.
Feb 23 2013