www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Alias syntax removal

reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Feb 10 2013
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 10 February 2013 at 13:13:12 UTC, bearophile wrote:

 Now I have a good amount of code broken by


Thanks to (absence of) D development model.


 I don't expect ...


Expecting something from how D is developed is not always a good 
idea:)


 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.
Feb 10 2013
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
2013/2/10 bearophile <bearophileHUGS lycos.com>


 Now I have a good amount of code broken by:

 alias x = 5;


This syntax never been valid in past, because alias declaration cannot make
alias of an expression.



 alias this = foo;


 This syntax was introduced very recent, in 2.061.

======


From 2.061, we have get new alias syntax by fixing issue 3011.


http://d.puremagic.com/issues/show_bug.cgi?id=3011

Now we can write alias declaration as follows:

alias Integer = int;
alias IntArray = int[];

These syntax are continuously valid in 2.062.

But, while a discussion for the compiler fix, a wrong syntax change, which
has similar look but definitely different meaning, had been introduced.
https://github.com/D-Programming-Language/dmd/pull/1187

struct S {
    int value;
    alias value this;   // old syntax
    alias this = value;  // new syntax, from 2.061
}


_accidentally_ released without deeply discussion.
https://github.com/D-Programming-Language/dmd/pull/1413

I think and believe that we MUST reset things.

Kenji Hara
Feb 10 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
kenji hara:


 This syntax never been valid in past, because alias declaration 
 cannot make alias of an expression.


Right, sorry, my mistake.



 Now we can write alias declaration as follows:

 alias Integer = int;
 alias IntArray = int[];

 These syntax are continuously valid in 2.062.


OK. So they aren't going away as I have feared.



 But, while a discussion for the compiler fix, a wrong syntax 
 change, which
 has similar look but definitely different meaning, had been 
 introduced.
 https://github.com/D-Programming-Language/dmd/pull/1187

 struct S {
     int value;
     alias value this;   // old syntax
     alias this = value;  // new syntax, from 2.061
 }


 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.


I see. Thank you for the work.

Bye,
bearophile
Feb 10 2013
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
2013/2/10 kenji hara <k.hara.pg gmail.com>



 _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? 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
Feb 10 2013
next sibling parent "Zoadian" <github zoadian.de> writes:
 `alias this : sym1, sym2, ...;` .


+1

clean and simple and consistent.
Feb 10 2013
prev sibling next sibling parent reply "Tove" <tove fransson.se> writes:
On Sunday, 10 February 2013 at 14:42:50 UTC, kenji hara wrote:

 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.
Feb 10 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/10/13, Tove <tove fransson.se> wrote:

 ... 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;
Feb 10 2013
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Feb 12 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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.
Feb 12 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
 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
Feb 23 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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>>



     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.
Feb 24 2013
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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....

Stewart.
Feb 11 2013
next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2013/2/11 Stewart Gordon <smjg_1998 yahoo.com>


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


*
*
*AliasDeclaration*: alias *BasicType*<http://dlang.org/declaration#BasicType>
 *Declarator* <http://dlang.org/declaration#Declarator> alias *
AliasInitializerList* <http://dlang.org/declaration#AliasInitializerList>*
AliasDeclaration*: alias *BasicType*<http://dlang.org/declaration#BasicType>
 *Declarator* <http://dlang.org/declaration#Declarator> alias *
AliasInitializerList* <http://dlang.org/declaration#AliasInitializerList>
http://dlang.org/declaration

AliasDeclaration:
    alias BasicType Declarator
    alias AliasInitializerList

AliasInitializerList:
    AliasInitializer
    AliasInitializer , AliasInitializerList

AliasInitializer:
    Identifier = Type

Kenji Hara
Feb 11 2013
prev sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
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.
Feb 11 2013