digitalmars.D - What happened to the alias this = identifier syntax in 2.062?
- Martin (9/9) Feb 22 2013 struct Test
- bearophile (5/6) Feb 22 2013 It was changed intentionally, but only for alias this. That
- Martin (3/9) Feb 22 2013 I see, thanks. What was the reason for not allowing alias this =
- deadalnix (2/14) Feb 22 2013 Requiring lookahead when parsing.
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (4/8) Feb 22 2013 It is a regression at best because it is nowhere to be found in the
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (4/12) Feb 22 2013 Posted:
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (8/21) Feb 22 2013 bearophile has added this link to the bug discussion:
- kenji hara (7/16) Feb 22 2013 .
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (12/26) Feb 22 2013 https://github.com/D-Programming-Language/d-programming-language.org/pul...
- Rob T (11/15) Feb 22 2013 You should not have to, and this is a problem with D that somehow
- deadalnix (5/13) Feb 22 2013 I also have to say that I fail to see the logic.
- Marco Leise (14/25) Feb 22 2013 =20
- Andrej Mitrovic (4/7) Feb 22 2013 It will be documented in the changelog once
- Timon Gehr (13/34) Feb 22 2013 It is nothing like that.
- Michael (1/8) Feb 22 2013 +1
- Joshua Niehus (2/4) Feb 22 2013 pseudonym foo;
- Timon Gehr (3/7) Feb 22 2013 auto opPseudonym() { ... }
- Joshua Niehus (26/28) Feb 22 2013 Isn't that creating multiple functions for the same thing?
- Joshua Niehus (13/13) Feb 22 2013 didn't fully formulate that thought:
- Chris Nicholson-Sauls (12/18) Feb 23 2013 I believe the alias syntax was based on typedef, which was
- Jonathan M Davis (19/38) Feb 23 2013 alias bar = foo;
- deadalnix (4/11) Feb 23 2013 It come with quite a lot of problems solved in an implementation
- Timon Gehr (4/13) Feb 22 2013 It is (embarrassingly!) intentional.
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
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
On Friday, 22 February 2013 at 14:55:19 UTC, bearophile wrote:Martin:I see, thanks. What was the reason for not allowing alias this = identifier?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
On Friday, 22 February 2013 at 14:58:02 UTC, Martin wrote:On Friday, 22 February 2013 at 14:55:19 UTC, bearophile wrote:Requiring lookahead when parsing.Martin:I see, thanks. What was the reason for not allowing alias this = identifier?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
On Friday, 22 February 2013 at 15:07:29 UTC, deadalnix wrote:On Friday, 22 February 2013 at 14:58:02 UTC, Martin wrote:Alright, thanks!On Friday, 22 February 2013 at 14:55:19 UTC, bearophile wrote:Requiring lookahead when parsing.Martin:I see, thanks. What was the reason for not allowing alias this = identifier?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
On Friday, 22 February 2013 at 15:31:43 UTC, Martin wrote:On Friday, 22 February 2013 at 15:07:29 UTC, deadalnix wrote: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.On Friday, 22 February 2013 at 14:58:02 UTC, Martin wrote:Alright, thanks!On Friday, 22 February 2013 at 14:55:19 UTC, bearophile wrote:Requiring lookahead when parsing.Martin:I see, thanks. What was the reason for not allowing alias this = identifier?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
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.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.Alright, thanks!Requiring lookahead when parsing.I see, thanks. What was the reason for not allowing alias this = identifier?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
On Friday, 22 February 2013 at 16:47:58 UTC, deadalnix wrote: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:It was wanted to distinguish the 2 with 2 different syntaxes.That's a very bad approach.
Sep 12 2014
On 02/22/2013 06:55 AM, bearophile wrote:Martin: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. AliWas 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.
Feb 22 2013
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 bestPosted: http://d.puremagic.com/issues/show_bug.cgi?id=9569 Ali
Feb 22 2013
On 02/22/2013 09:27 AM, Ali Çehreli wrote:On 02/22/2013 09:08 AM, Ali Çehreli wrote: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. AliOn 02/22/2013 06:55 AM, bearophile wrote:Posted: http://d.puremagic.com/issues/show_bug.cgi?id=9569 AliMartin:It is a regression at bestWas 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.
Feb 22 2013
2013/2/23 Ali =C3=87ehreli <acehreli yahoo.com>On 02/22/2013 06:55 AM, bearophile wrote:. 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 HaraMartin: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=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.
Feb 22 2013
On 02/22/2013 09:28 AM, kenji hara wrote:2013/2/23 Ali Çehreli<acehreli yahoo.com>lists.On 02/22/2013 06:55 AM, bearophile wrote:Martin: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 thoseWas 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.That is intended change. https://github.com/D-Programming-Language/dmd/issues/1413https://github.com/D-Programming-Language/d-programming-language.org/pull/224 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
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. AliYou 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
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
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==20fixed as quickly as possible. =20 I have a feeling that there must have been some newsgroup discussions as==20well but unfortunately I must have been busy with other things at the=20 time. Not all of us read github. =20 AliNo, 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
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
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>: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.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. AliNo, 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.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
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
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
On 02/23/2013 12:10 AM, Joshua Niehus wrote:On Friday, 22 February 2013 at 21:23:04 UTC, Timon Gehr wrote:auto opPseudonym() { ... } alias opPseudonym=foo;[snip].. or the alias this syntax should be deprecated in favour of a specially named member function.pseudonym foo;
Feb 22 2013
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
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
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
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: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.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.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
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
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