www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UFCS idea

reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
There have been several topics discussing UFCS recently. So here is one 
more)
One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
e.g. you have some function:
void func(Type1 p1, Type2 p2);

and later call it:
fucn(a, b);  //or
a.func( _, b);  //or
b.func(a,  _);

This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);
would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);

Which is a little longer. On the other side this way benefits from:
 * UFCS is directly seen by both the programmer and compiler;
 * UFCS doesn't mix with member call syntax;
 * UFCS can be used for any type and for any argument, e.g.
    a.func( , b) or b.func(a,  );
 * UFCS can be used for more than one argument: a.func( _,  _~[1]);

What do you think? 
Jun 08 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
 _ <- that's a snail.
Jun 08 2011
parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> ???????/???????? ? ???????? 
?????????: news:mailman.717.1307563594.14074.digitalmars-d puremagic.com...
  _ <- that's a snail.

Jun 08 2011
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 08.06.2011 23:41, Alex_Dovhal wrote:
 There have been several topics discussing UFCS recently. So here is one
 more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);

 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);

 This way Timon Gehr's example:
      take(10,stride(2,cycle([3,2,5,3])));
      [3,2,5,3].cycle().stride(2).take(10);
 would be written as this:
      [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);

 Which is a little longer. On the other side this way benefits from:
   * UFCS is directly seen by both the programmer and compiler;
   * UFCS doesn't mix with member call syntax;
   * UFCS can be used for any type and for any argument, e.g.
      a.func( , b) or b.func(a,  );
   * UFCS can be used for more than one argument: a.func( _,  _~[1]);

 What do you think?

what was so bad about having 'this' inside parameters? I thought it was rather compelling: void func(Type1 this, Type2 p2); which is legal only as a free function and inside structs/classes it's declaration syntax error. [3,2,5,3].cycle.stride(2).take(10); //and no snails :) -- Dmitry Olshansky
Jun 08 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
Dmitry Olshansky wrote:
 what was so bad about having 'this' inside parameters?
 I thought it was rather compelling:

 void func(Type1 this, Type2 p2);
 which is legal only as a free function and inside structs/classes it's

 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)

Furthermore, it should be illegal to make UFCS clash with a method's name in order to prevent hijacking. Timon
Jun 08 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 09.06.2011 0:39, Timon Gehr wrote:
 Dmitry Olshansky wrote:
 what was so bad about having 'this' inside parameters?
 I thought it was rather compelling:

 void func(Type1 this, Type2 p2);
 which is legal only as a free function and inside structs/classes it's

 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)

to prevent hijacking.

the same way - partial ordering, and report ambiguity if can't choose one. Less special casing.
 Timon

-- Dmitry Olshansky
Jun 08 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
 Dmitry Olshansky wrote:
 On 09.06.2011 0:39, Timon Gehr wrote:
 Dmitry Olshansky wrote:
 what was so bad about having 'this' inside parameters?
 I thought it was rather compelling:

 void func(Type1 this, Type2 p2);
 which is legal only as a free function and inside structs/classes it's

 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)

to prevent hijacking.

the same way - partial ordering, and report ambiguity if can't choose one. Less special casing.
 Timon


How does that prevent hijacking? If you want it to overload against members of the same name, you would have to introduce another overload set, not just another overload. (But indeed, that would be more consistent.) Timon
Jun 08 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 09.06.2011 0:48, Timon Gehr wrote:
 Dmitry Olshansky wrote:
 On 09.06.2011 0:39, Timon Gehr wrote:
 Dmitry Olshansky wrote:
 what was so bad about having 'this' inside parameters?
 I thought it was rather compelling:

 void func(Type1 this, Type2 p2);
 which is legal only as a free function and inside structs/classes it's

 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)

to prevent hijacking.

the same way - partial ordering, and report ambiguity if can't choose one. Less special casing.
 Timon


same name, you would have to introduce another overload set, not just another overload. (But indeed, that would be more consistent.)

two overload sets: first is used when it's called as member function, the set consists of all UFCS functions & member functions with the same name. second is used when it's called as free function, the set consists of all UFCS functions & free functions with the same name. -- Dmitry Olshansky
Jun 08 2011
parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Dmitry Olshansky" <dmitry.olsh gmail.com> ???????/???????? ? ???????? 
?????????: news:isopbg$1l5d$1 digitalmars.com...
 How does that prevent hijacking? If you want it to overload against 
 members of the
 same name, you would have to introduce another overload set, not just 
 another
 overload. (But indeed, that would be more consistent.)

overload sets: first is used when it's called as member function, the set consists of all UFCS functions & member functions with the same name. second is used when it's called as free function, the set consists of all UFCS functions & free functions with the same name. -- Dmitry Olshansky

Yes, but imagine you have a situation: someLib.d: class A{ void member1(int a); void member2(int a); ... } someUserCode.d: void member3(A this, int a); //local user func ... member3(x, 1); //hundred times in user code And later library writer adds void member3(int a) member to class A. Now user code has name collision.
Jun 08 2011
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 09.06.2011 1:41, Alex_Dovhal wrote:
 "Dmitry Olshansky"<dmitry.olsh gmail.com>  ???????/???????? ? ????????
 ?????????: news:isopbg$1l5d$1 digitalmars.com...
 How does that prevent hijacking? If you want it to overload against
 members of the
 same name, you would have to introduce another overload set, not just
 another
 overload. (But indeed, that would be more consistent.)

overload sets: first is used when it's called as member function, the set consists of all UFCS functions& member functions with the same name. second is used when it's called as free function, the set consists of all UFCS functions& free functions with the same name. -- Dmitry Olshansky

someLib.d: class A{ void member1(int a); void member2(int a); ... } someUserCode.d: void member3(A this, int a); //local user func .... member3(x, 1); //hundred times in user code And later library writer adds void member3(int a) member to class A. Now user code has name collision.

Since UFCS is exactly to allow it to behave like a method isn't it? It's not like UFCS will solve this kind of problem staying what it is. -- Dmitry Olshansky
Jun 08 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
Alex Dovhal wrote:
 Yes, but imagine you have a situation:
 someLib.d:
 class A{
     void member1(int a);
     void member2(int a);
     ...
 }

 someUserCode.d:
 void member3(A this, int a); //local user func
 ...
 member3(x, 1); //hundred times in user code

 And later library writer adds void member3(int a) member to class A.
 Now user code has name collision.

No, his 100 calls are all unambiguous. Timon
Jun 08 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 09.06.2011 1:55, Timon Gehr wrote:
 Alex Dovhal wrote:
 Yes, but imagine you have a situation:
 someLib.d:
 class A{
      void member1(int a);
      void member2(int a);
      ...
 }

 someUserCode.d:
 void member3(A this, int a); //local user func
 ...
 member3(x, 1); //hundred times in user code

 And later library writer adds void member3(int a) member to class A.
 Now user code has name collision.


e.g. x.member3(1) --> member3(x, 1); but it would be an unpleasant surprise in this case, suppose his 101th call looked like: x.member3(1) then after change it suddenly stops calling his code, and calls library code. And silently! So I think UFCS should work in both directions. -- Dmitry Olshansky
Jun 08 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
Dmitry Olshansky wrote:
 On 09.06.2011 1:55, Timon Gehr wrote:
 Alex Dovhal wrote:
 Yes, but imagine you have a situation:
 someLib.d:
 class A{
      void member1(int a);
      void member2(int a);
      ...
 }

 someUserCode.d:
 void member3(A this, int a); //local user func
 ...
 member3(x, 1); //hundred times in user code

 And later library writer adds void member3(int a) member to class A.
 Now user code has name collision.


e.g. x.member3(1) --> member3(x, 1); but it would be an unpleasant surprise in this case, suppose his 101th call looked like: x.member3(1) then after change it suddenly stops calling his code, and calls library code. And silently!

No. _That_ code would blow up during compilation because it is an ambiguous call. It's iust like the rest of D.
 So I think UFCS should work in both directions.

I don't. I do not see any use case for the other direction. (and it would be really screwy anyways) Use UFCS if you want both to be valid. Timon
Jun 08 2011
prev sibling parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Alex_Dovhal" <alex_dovhal yahoo.com>wrote:...
[snip]
 member3(x, 1); //hundred times in user code

 And later library writer adds void member3(int a) member to class A.
 Now user code has name collision.

Jun 08 2011
prev sibling parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Dmitry Olshansky" <dmitry.olsh gmail.com> wrote
 what was so bad about having 'this' inside parameters?
 I thought it was rather compelling:

 void func(Type1 this, Type2 p2);
 which is legal only as a free function and inside structs/classes it's 
 declaration syntax error.

 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)



 -- 
 Dmitry Olshansky

UFCS with 'this' is not bad. I've just got another competitive idea which i'd like to discuss.
[3,2,5,3].cycle.stride(2).take(10); //and no snails :)

UFCS? And which argument to it is one before dot? Sure here you can, but in more complex cases or when you don't want to strain you mind and memory. a.someUnknownToReaderFunc(b).otherNotOftenUsedFunc(c)
Jun 08 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 09.06.2011 1:30, Alex_Dovhal wrote:
 "Dmitry Olshansky"<dmitry.olsh gmail.com>  wrote
 what was so bad about having 'this' inside parameters?
 I thought it was rather compelling:

 void func(Type1 this, Type2 p2);
 which is legal only as a free function and inside structs/classes it's
 declaration syntax error.

 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)



 -- 
 Dmitry Olshansky

i'd like to discuss.
 [3,2,5,3].cycle.stride(2).take(10); //and no snails :)

UFCS?

substitute for method(x,...) ? :) Well, and to me having some freedom in position of this argument seems OK.
 And which argument to it is one before dot?

likely the first ? ;) Clearly there is a potential to abuse, but you can abuse a whole lot of other features.
 Sure here you can, but in more complex cases or when you don't want to
 strain you mind and memory.
 a.someUnknownToReaderFunc(b).otherNotOftenUsedFunc(c)

small subset of those) anyway, not some scary monsters from hell. And you'd have to strain your mind and memory to check docs anyway. And of course bad pick of position for this argument is clearly possible. It's good thing that it remains in control of library writer, not user. Thus combinations stay limited, as careful library writer is usually expected thing, as for user it's not exactly. -- Dmitry Olshansky
Jun 08 2011
parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Dmitry Olshansky" <dmitry.olsh gmail.com> wrote:
 Sure here you can, but in more complex cases or when you don't want to
 strain you mind and memory.
 a.someUnknownToReaderFunc(b).otherNotOftenUsedFunc(c)

small subset of those) anyway, not some scary monsters from hell. And you'd have to strain your mind and memory to check docs anyway. And of course bad pick of position for this argument is clearly possible. It's good thing that it remains in control of library writer, not user. Thus combinations stay limited, as careful library writer is usually expected thing, as for user it's not exactly.

Agree.
Jun 08 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e68ee44d76905c04a5424c35
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal yahoo.com> wrote:

 There have been several topics discussing UFCS recently. So here is one
 more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);

 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);

 This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);
 would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);

 Which is a little longer. On the other side this way benefits from:
  * UFCS is directly seen by both the programmer and compiler;
  * UFCS doesn't mix with member call syntax;
  * UFCS can be used for any type and for any argument, e.g.
    a.func( , b) or b.func(a,  );
  * UFCS can be used for more than one argument: a.func( _,  _~[1]);

 What do you think?

I find it funny that was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of the rules for annotations is that they cannot directly alter the code the compiler outputs. You can add plugins to the Java compiler that use annotations to modify the AST before it's compiled, and you can use annotations for runtime bytecode generation or interpret them using reflection, but if you take unannotated code and annotated code and compile it (without altering the compiler), the generated code will not change. The idea was to make them a part of the language composed entirely of metadata (some of which was enforced to be correct by the compiler) that could be completely ignored if the programmer didn't want to use it. Now that D has taken up this syntax, we've done almost the opposite. is mostly used in situations where it changes the compiled code, changes the existing language, and is in no way optional. We don't really support user defined metadata, and we can't use what annotations we have as metadata because only the compiler can actually use it. Most of the uses I've seen seem to be a way to cram more keywords into the language without adding more keywords. I've been holding in this sort of rant for a while, but in summary, my response is that unless the desired use for was defined radically differently by D when it was adopted (and, as far as I can tell, it wasn't), seeing another abuse of it just makes me feel slightly sick inside. --0016e68ee44d76905c04a5424c35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:alex_dovhal yahoo.com">alex_dovhal yah= oo.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> There have been several topics discussing UFCS recently. So here is one<br> more)<br> One idea about UFCS - mark UFCS argument with , _, or _ symbol,<br> e.g. you have some function:<br> void func(Type1 p1, Type2 p2);<br> <br> and later call it:<br> fucn(a, b); =A0//or<br> a.func( _, b); =A0//or<br> b.func(a, _);<br> <br> This way Timon Gehr&#39;s example:<br> =A0 =A0take(10,stride(2,cycle([3,2,5,3])));<br> =A0 =A0[3,2,5,3].cycle().stride(2).take(10);<br> would be written as this:<br> =A0 =A0[3,2,5,3].cycle( _).stride(2, _).take(10, _);<br> <br> Which is a little longer. On the other side this way benefits from:<br> =A0* UFCS is directly seen by both the programmer and compiler;<br> =A0* UFCS doesn&#39;t mix with member call syntax;<br> =A0* UFCS can be used for any type and for any argument, e.g.<br> =A0 =A0a.func( , b) or b.func(a, );<br> =A0* UFCS can be used for more than one argument: a.func( _, _~[1]);<br> <br> What do you think?<br> <br> <br> </blockquote></div><br><div><br></div><div>I find it funny that was initi= ally adopted for annotations, to be used similar to Java and Scala. I come = from that world, and one of the rules for annotations is that they cannot d= irectly alter the code the compiler outputs. You can add plugins to the Jav= a compiler that use annotations to modify the AST before it&#39;s compiled,= and you can use annotations for runtime bytecode generation or interpret t= hem using reflection, but if you take unannotated code and annotated code a= nd compile it (without altering the compiler), the generated code will not = change.</div> <div>The idea was to make them a part of the language composed entirely of = metadata (some of which was enforced to be correct by the compiler) that co= uld be completely ignored if the programmer didn&#39;t want to use it.</div=

<div>Now that D has taken up this syntax, we&#39;ve done almost the opposit= e. is mostly used in situations where it changes the compiled code, chang= es the existing language, =A0and is in no way optional. We don&#39;t really= support user defined metadata, and we can&#39;t use what annotations we ha= ve as metadata because only the compiler can actually use it. Most of the u= ses I&#39;ve seen seem to be a way to cram more keywords into the language = without adding more keywords.</div> <div>I&#39;ve been holding in this sort of rant for a while, but in summary= , my response is that unless the desired use for was defined radically di= fferently by D when it was adopted (and, as far as I can tell, it wasn&#39;= t), seeing another abuse of it just makes me feel slightly sick inside.</di= v> --0016e68ee44d76905c04a5424c35--
Jun 09 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-09 00:20, Andrew Wiley wrote:
 On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal yahoo.com> wrote:
 There have been several topics discussing UFCS recently. So here is one
 more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);
 
 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);
 
 This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);
 
 would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);
 
 Which is a little longer. On the other side this way benefits from:
  * UFCS is directly seen by both the programmer and compiler;
  * UFCS doesn't mix with member call syntax;
  * UFCS can be used for any type and for any argument, e.g.
  
    a.func( , b) or b.func(a,  );
  
  * UFCS can be used for more than one argument: a.func( _,  _~[1]);
 
 What do you think?

I find it funny that was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of the rules for annotations is that they cannot directly alter the code the compiler outputs. You can add plugins to the Java compiler that use annotations to modify the AST before it's compiled, and you can use annotations for runtime bytecode generation or interpret them using reflection, but if you take unannotated code and annotated code and compile it (without altering the compiler), the generated code will not change. The idea was to make them a part of the language composed entirely of metadata (some of which was enforced to be correct by the compiler) that could be completely ignored if the programmer didn't want to use it. Now that D has taken up this syntax, we've done almost the opposite. is mostly used in situations where it changes the compiled code, changes the existing language, and is in no way optional. We don't really support user defined metadata, and we can't use what annotations we have as metadata because only the compiler can actually use it. Most of the uses I've seen seem to be a way to cram more keywords into the language without adding more keywords. I've been holding in this sort of rant for a while, but in summary, my response is that unless the desired use for was defined radically differently by D when it was adopted (and, as far as I can tell, it wasn't), seeing another abuse of it just makes me feel slightly sick inside.

As it is, user-defined attributes can be added later using the syntax. True, all of the current uses of are for where we decided to save a keyword, but that doesn't stop user-defined attributes from using the syntax later. It just means that those that are currently defined will always be special. Regardless, I see little point in using it for UFCS. If we want to specifically mark parameters for it, I think that the suggestion of using "this" makes a lot more sense. You wouldn't even have to change the grammar (unlike if you used ). You'd just change the semantic phase to treat "this" specially as a function parameter and not freak out about it being a keyword. Using would be a much bigger language change and for no gain whatsoever as far as I can see. - Jonathan M Davis
Jun 09 2011
parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wote:
 Regardless, I see little point in using it for UFCS. If we want to
 specifically mark parameters for it, I think that the suggestion of using
 "this" makes a lot more sense. You wouldn't even have to change the 
 grammar
 (unlike if you used  ). You'd just change the semantic phase to treat 
 "this"
 specially as a function parameter and not freak out about it being a 
 keyword.
 Using   would be a much bigger language change and for no gain whatsoever 
 as
 far as I can see.

 - Jonathan M Davis

Thanks, Dmitry Olshansky has already explained why using "this" is fully suitable. One thing I personally dislike in UFCS is that it's impossible to visually separate it from member call syntax, only by context. But this is only personal taste. Sorry for noise.
Jun 09 2011
prev sibling next sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e68ee44d53c56504a543106b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On 2011-06-09 00:20, Andrew Wiley wrote:
 On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal yahoo.com>

 There have been several topics discussing UFCS recently. So here is one
 more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);

 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);

 This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);

 would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);

 Which is a little longer. On the other side this way benefits from:
  * UFCS is directly seen by both the programmer and compiler;
  * UFCS doesn't mix with member call syntax;
  * UFCS can be used for any type and for any argument, e.g.

    a.func( , b) or b.func(a,  );

  * UFCS can be used for more than one argument: a.func( _,  _~[1]);

 What do you think?

I find it funny that was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of the rules

 annotations is that they cannot directly alter the code the compiler
 outputs. You can add plugins to the Java compiler that use annotations to
 modify the AST before it's compiled, and you can use annotations for
 runtime bytecode generation or interpret them using reflection, but if

 take unannotated code and annotated code and compile it (without altering
 the compiler), the generated code will not change.
 The idea was to make them a part of the language composed entirely of
 metadata (some of which was enforced to be correct by the compiler) that
 could be completely ignored if the programmer didn't want to use it.
 Now that D has taken up this syntax, we've done almost the opposite.   is
 mostly used in situations where it changes the compiled code, changes the
 existing language,  and is in no way optional. We don't really support

 defined metadata, and we can't use what annotations we have as metadata
 because only the compiler can actually use it. Most of the uses I've seen
 seem to be a way to cram more keywords into the language without adding
 more keywords.
 I've been holding in this sort of rant for a while, but in summary, my
 response is that unless the desired use for   was defined radically
 differently by D when it was adopted (and, as far as I can tell, it
 wasn't), seeing another abuse of it just makes me feel slightly sick
 inside.

As it is, user-defined attributes can be added later using the syntax. True, all of the current uses of are for where we decided to save a keyword, but that doesn't stop user-defined attributes from using the syntax later. It just means that those that are currently defined will always be special.

This is the difference in philosophy at the core of my general unhappiness. When Java officially added annotations, they were designed and built to be used for user-defined metadata. We added "Property" to the grammar, celebrated that we had them too, then stopped. The result is that we're throwing around as an excuse for language keywords and boasting about how we have annotations when, by the definition of any other language, we simply don't. I guess the best answer from where I'm standing is to start throwing around possible syntaxes for annotation declarations and references to them in compile-time reflection. I just really hope this gets in to D2, so we aren't permanently stuck with "fake annotations." Regardless, I see little point in using it for UFCS. If we want to
 specifically mark parameters for it, I think that the suggestion of using
 "this" makes a lot more sense. You wouldn't even have to change the grammar
 (unlike if you used  ). You'd just change the semantic phase to treat
 "this"
 specially as a function parameter and not freak out about it being a
 keyword.
 Using   would be a much bigger language change and for no gain whatsoever
 as
 far as I can see.

--0016e68ee44d53c56504a543106b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davi= s <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg = gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On 2011-06-09 00:20, Andrew Wiley wrote:<= br> &gt; On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal &lt;<a href=3D"mailto:ale= x_dovhal yahoo.com">alex_dovhal yahoo.com</a>&gt; wrote:<br> &gt; &gt; There have been several topics discussing UFCS recently. So here = is one<br> &gt; &gt; more)<br> &gt; &gt; One idea about UFCS - mark UFCS argument with , _, or _ symbol,= <br> &gt; &gt; e.g. you have some function:<br> &gt; &gt; void func(Type1 p1, Type2 p2);<br> &gt; &gt;<br> &gt; &gt; and later call it:<br> &gt; &gt; fucn(a, b); =A0//or<br> &gt; &gt; a.func( _, b); =A0//or<br> &gt; &gt; b.func(a, _);<br> &gt; &gt;<br> &gt; &gt; This way Timon Gehr&#39;s example:<br> &gt; &gt; =A0 =A0take(10,stride(2,cycle([3,2,5,3])));<br> &gt; &gt; =A0 =A0[3,2,5,3].cycle().stride(2).take(10);<br> &gt; &gt;<br> &gt; &gt; would be written as this:<br> &gt; &gt; =A0 =A0[3,2,5,3].cycle( _).stride(2, _).take(10, _);<br> &gt; &gt;<br> &gt; &gt; Which is a little longer. On the other side this way benefits fro= m:<br> &gt; &gt; =A0* UFCS is directly seen by both the programmer and compiler;<b= r> &gt; &gt; =A0* UFCS doesn&#39;t mix with member call syntax;<br> &gt; &gt; =A0* UFCS can be used for any type and for any argument, e.g.<br> &gt; &gt;<br> &gt; &gt; =A0 =A0a.func( , b) or b.func(a, );<br> &gt; &gt;<br> &gt; &gt; =A0* UFCS can be used for more than one argument: a.func( _, _~[= 1]);<br> &gt; &gt;<br> &gt; &gt; What do you think?<br> &gt;<br> &gt; I find it funny that was initially adopted for annotations, to be us= ed<br> &gt; similar to Java and Scala. I come from that world, and one of the rule= s for<br> &gt; annotations is that they cannot directly alter the code the compiler<b= r> &gt; outputs. You can add plugins to the Java compiler that use annotations= to<br> &gt; modify the AST before it&#39;s compiled, and you can use annotations f= or<br> &gt; runtime bytecode generation or interpret them using reflection, but if= you<br> &gt; take unannotated code and annotated code and compile it (without alter= ing<br> &gt; the compiler), the generated code will not change.<br> &gt; The idea was to make them a part of the language composed entirely of<= br> &gt; metadata (some of which was enforced to be correct by the compiler) th= at<br> &gt; could be completely ignored if the programmer didn&#39;t want to use i= t.<br> &gt; Now that D has taken up this syntax, we&#39;ve done almost the opposit= e. is<br> &gt; mostly used in situations where it changes the compiled code, changes = the<br> &gt; existing language, =A0and is in no way optional. We don&#39;t really s= upport user<br> &gt; defined metadata, and we can&#39;t use what annotations we have as met= adata<br> &gt; because only the compiler can actually use it. Most of the uses I&#39;= ve seen<br> &gt; seem to be a way to cram more keywords into the language without addin= g<br> &gt; more keywords.<br> &gt; I&#39;ve been holding in this sort of rant for a while, but in summary= , my<br> &gt; response is that unless the desired use for was defined radically<br=


ck<br> &gt; inside.<br> <br> </div></div>As it is, user-defined attributes can be added later using the = syntax. True,<br> all of the current uses of are for where we decided to save a keyword, bu= t<br> that doesn&#39;t stop user-defined attributes from using the syntax later. = It just<br> means that those that are currently defined will always be special.<br></bl= ockquote><div><br></div><div>This is the difference in philosophy at the co= re of my general unhappiness. When Java officially added annotations, they = were designed and built to be used for user-defined metadata. We added &quo= t;Property&quot; to the grammar, celebrated that we had them too, then stop= ped. The result is that we&#39;re throwing around as an excuse for langua= ge keywords and boasting about how we have annotations when, by the definit= ion of any other language, we simply don&#39;t.</div> <div>I guess the best answer from where I&#39;m standing is to start throwi= ng around possible syntaxes for annotation declarations and references to t= hem in compile-time reflection. I just really hope this gets in to D2, so w= e aren&#39;t permanently stuck with &quot;fake annotations.&quot;</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Regardless, I see little point in using it for UFCS. If we want to<br> specifically mark parameters for it, I think that the suggestion of using<b= r> &quot;this&quot; makes a lot more sense. You wouldn&#39;t even have to chan= ge the grammar<br> (unlike if you used ). You&#39;d just change the semantic phase to treat &= quot;this&quot;<br> specially as a function parameter and not freak out about it being a keywor= d.<br> Using would be a much bigger language change and for no gain whatsoever a= s<br> far as I can see.<br> <font color=3D"#888888"><br></font></blockquote><div><br></div><div>I agree= . The &quot;this&quot; syntax seems far more logical and straightforward.</= div></div><br> --0016e68ee44d53c56504a543106b--
Jun 09 2011
parent Kagamin <spam here.lot> writes:
Andrew Wiley Wrote:

 celebrated that we had them too, then stopped. The result is that we're
 throwing around   as an excuse for language keywords and boasting about how
 we have annotations when, by the definition of any other language, we simply
 don't.

By "any other language" you must mean C# :)
Jun 09 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-09 01:15, Andrew Wiley wrote:
 On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis 

 On 2011-06-09 00:20, Andrew Wiley wrote:
 On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal yahoo.com>

wrote:
 There have been several topics discussing UFCS recently. So here is
 one more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);
 
 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);
 
 This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);
 
 would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);
 
 Which is a little longer. On the other side this way benefits from:
  * UFCS is directly seen by both the programmer and compiler;
  * UFCS doesn't mix with member call syntax;
  * UFCS can be used for any type and for any argument, e.g.
  
    a.func( , b) or b.func(a,  );
  
  * UFCS can be used for more than one argument: a.func( _,  _~[1]);
 
 What do you think?

I find it funny that was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of the rules

for
 annotations is that they cannot directly alter the code the compiler
 outputs. You can add plugins to the Java compiler that use annotations
 to modify the AST before it's compiled, and you can use annotations
 for runtime bytecode generation or interpret them using reflection,
 but if

you
 take unannotated code and annotated code and compile it (without
 altering the compiler), the generated code will not change.
 The idea was to make them a part of the language composed entirely of
 metadata (some of which was enforced to be correct by the compiler)
 that could be completely ignored if the programmer didn't want to use
 it. Now that D has taken up this syntax, we've done almost the
 opposite.   is mostly used in situations where it changes the compiled
 code, changes the existing language,  and is in no way optional. We
 don't really support

user
 defined metadata, and we can't use what annotations we have as metadata
 because only the compiler can actually use it. Most of the uses I've
 seen seem to be a way to cram more keywords into the language without
 adding more keywords.
 I've been holding in this sort of rant for a while, but in summary, my
 response is that unless the desired use for   was defined radically
 differently by D when it was adopted (and, as far as I can tell, it
 wasn't), seeing another abuse of it just makes me feel slightly sick
 inside.

As it is, user-defined attributes can be added later using the syntax. True, all of the current uses of are for where we decided to save a keyword, but that doesn't stop user-defined attributes from using the syntax later. It just means that those that are currently defined will always be special.

This is the difference in philosophy at the core of my general unhappiness. When Java officially added annotations, they were designed and built to be used for user-defined metadata. We added "Property" to the grammar, celebrated that we had them too, then stopped. The result is that we're throwing around as an excuse for language keywords and boasting about how we have annotations when, by the definition of any other language, we simply don't. I guess the best answer from where I'm standing is to start throwing around possible syntaxes for annotation declarations and references to them in compile-time reflection. I just really hope this gets in to D2, so we aren't permanently stuck with "fake annotations."

I don't really see anything wrong with leaving the current attributes as they are and then just using for user-defined attributes as well. There will just be a set of attribute names which are reserved by the compiler. All that using a different syntax for user-defined attributes would buy you would be that you could use the attribute names that the compiler has reserved - safe, trusted, system, and property. And that isn't exactly a huge gain. We might as well just use for user-defined attributes as well. - Jonathan M Davis
Jun 09 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e6d273a8469bac04a54c1803
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 9, 2011 at 4:29 AM, Kagamin <spam here.lot> wrote:

 Andrew Wiley Wrote:

 celebrated that we had them too, then stopped. The result is that we're
 throwing around   as an excuse for language keywords and boasting about

 we have annotations when, by the definition of any other language, we

 don't.

By "any other language" you must mean C# :)

And Java/Scala. --0016e6d273a8469bac04a54c1803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Jun 9, 2011 at 4:29 AM, Kagamin = <span dir=3D"ltr">&lt;spam here.lot&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor= der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty= le: solid;"> <div class=3D"im">Andrew Wiley Wrote:<br> <br> &gt; celebrated that we had them too, then stopped. The result is that we&#= 39;re<br> &gt; throwing around as an excuse for language keywords and boasting abou= t how<br> &gt; we have annotations when, by the definition of any other language, we = simply<br> &gt; don&#39;t.<br> <br> </div>By &quot;any other language&quot; you must mean C# :)<br> </blockquote></div><div>=A0</div><div>And Java/Scala.<br></div> --0016e6d273a8469bac04a54c1803--
Jun 09 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e6d273a8f20be404a54c1574
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 9, 2011 at 1:32 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On 2011-06-09 01:15, Andrew Wiley wrote:
 On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis

 On 2011-06-09 00:20, Andrew Wiley wrote:
 On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal yahoo.com>

wrote:
 There have been several topics discussing UFCS recently. So here is
 one more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);

 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);

 This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);

 would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);

 Which is a little longer. On the other side this way benefits from:
  * UFCS is directly seen by both the programmer and compiler;
  * UFCS doesn't mix with member call syntax;
  * UFCS can be used for any type and for any argument, e.g.

    a.func( , b) or b.func(a,  );

  * UFCS can be used for more than one argument: a.func( _,  _~[1]);

 What do you think?

I find it funny that was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of



 rules

for
 annotations is that they cannot directly alter the code the compiler
 outputs. You can add plugins to the Java compiler that use



 to modify the AST before it's compiled, and you can use annotations
 for runtime bytecode generation or interpret them using reflection,
 but if

you
 take unannotated code and annotated code and compile it (without
 altering the compiler), the generated code will not change.
 The idea was to make them a part of the language composed entirely of
 metadata (some of which was enforced to be correct by the compiler)
 that could be completely ignored if the programmer didn't want to use
 it. Now that D has taken up this syntax, we've done almost the
 opposite.   is mostly used in situations where it changes the



 code, changes the existing language,  and is in no way optional. We
 don't really support

user
 defined metadata, and we can't use what annotations we have as



 because only the compiler can actually use it. Most of the uses I've
 seen seem to be a way to cram more keywords into the language without
 adding more keywords.
 I've been holding in this sort of rant for a while, but in summary,



 response is that unless the desired use for   was defined radically
 differently by D when it was adopted (and, as far as I can tell, it
 wasn't), seeing another abuse of it just makes me feel slightly sick
 inside.

As it is, user-defined attributes can be added later using the


 True,
 all of the current uses of   are for where we decided to save a


 but
 that doesn't stop user-defined attributes from using the syntax later.


 just
 means that those that are currently defined will always be special.

This is the difference in philosophy at the core of my general

 When Java officially added annotations, they were designed and built to

 used for user-defined metadata. We added "Property" to the grammar,
 celebrated that we had them too, then stopped. The result is that we're
 throwing around   as an excuse for language keywords and boasting about

 we have annotations when, by the definition of any other language, we
 simply don't.
 I guess the best answer from where I'm standing is to start throwing

 possible syntaxes for annotation declarations and references to them in
 compile-time reflection. I just really hope this gets in to D2, so we
 aren't permanently stuck with "fake annotations."

I don't really see anything wrong with leaving the current attributes as they are and then just using for user-defined attributes as well. There will just be a set of attribute names which are reserved by the compiler. All that using a different syntax for user-defined attributes would buy you would be that you could use the attribute names that the compiler has reserved - safe, trusted, system, and property. And that isn't exactly a huge gain. We might as well just use for user-defined attributes as well.

My point wasn't that the syntax should be different (it should definitely be the same), my point was that we stopped short of fully implementing annotation support and that the result seems to be significantly less than ideal.

--0016e6d273a8f20be404a54c1574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Jun 9, 2011 at 1:32 AM, Jonathan M Davis= <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg g= mx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2= 04, 204); border-left-width: 1px; border-left-style: solid;"> <div><div></div><div class=3D"h5">On 2011-06-09 01:15, Andrew Wiley wrote:<= br> &gt; On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis<br> &lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;wrote= :<br> &gt; &gt; On 2011-06-09 00:20, Andrew Wiley wrote:<br> &gt; &gt; &gt; On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal &lt;<a href=3D"= mailto:alex_dovhal yahoo.com">alex_dovhal yahoo.com</a>&gt;<br> &gt; &gt;<br> &gt; &gt; wrote:<br> &gt; &gt; &gt; &gt; There have been several topics discussing UFCS recently= . So here is<br> &gt; &gt; &gt; &gt; one more)<br> &gt; &gt; &gt; &gt; One idea about UFCS - mark UFCS argument with , _, or= _ symbol,<br> &gt; &gt; &gt; &gt; e.g. you have some function:<br> &gt; &gt; &gt; &gt; void func(Type1 p1, Type2 p2);<br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; and later call it:<br> &gt; &gt; &gt; &gt; fucn(a, b); =A0//or<br> &gt; &gt; &gt; &gt; a.func( _, b); =A0//or<br> &gt; &gt; &gt; &gt; b.func(a, _);<br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; This way Timon Gehr&#39;s example:<br> &gt; &gt; &gt; &gt; =A0 =A0take(10,stride(2,cycle([3,2,5,3])));<br> &gt; &gt; &gt; &gt; =A0 =A0[3,2,5,3].cycle().stride(2).take(10);<br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; would be written as this:<br> &gt; &gt; &gt; &gt; =A0 =A0[3,2,5,3].cycle( _).stride(2, _).take(10, _);<= br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; Which is a little longer. On the other side this way be= nefits from:<br> &gt; &gt; &gt; &gt; =A0* UFCS is directly seen by both the programmer and c= ompiler;<br> &gt; &gt; &gt; &gt; =A0* UFCS doesn&#39;t mix with member call syntax;<br> &gt; &gt; &gt; &gt; =A0* UFCS can be used for any type and for any argument= , e.g.<br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; =A0 =A0a.func( , b) or b.func(a, );<br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; =A0* UFCS can be used for more than one argument: a.fun= c( _, _~[1]);<br> &gt; &gt; &gt; &gt;<br> &gt; &gt; &gt; &gt; What do you think?<br> &gt; &gt; &gt;<br> &gt; &gt; &gt; I find it funny that was initially adopted for annotations= , to be<br> &gt; &gt; &gt; used similar to Java and Scala. I come from that world, and = one of the<br> &gt; &gt; &gt; rules<br> &gt; &gt;<br> &gt; &gt; for<br> &gt; &gt;<br> &gt; &gt; &gt; annotations is that they cannot directly alter the code the = compiler<br> &gt; &gt; &gt; outputs. You can add plugins to the Java compiler that use a= nnotations<br> &gt; &gt; &gt; to modify the AST before it&#39;s compiled, and you can use = annotations<br> &gt; &gt; &gt; for runtime bytecode generation or interpret them using refl= ection,<br> &gt; &gt; &gt; but if<br> &gt; &gt;<br> &gt; &gt; you<br> &gt; &gt;<br> &gt; &gt; &gt; take unannotated code and annotated code and compile it (wit= hout<br> &gt; &gt; &gt; altering the compiler), the generated code will not change.<= br> &gt; &gt; &gt; The idea was to make them a part of the language composed en= tirely of<br> &gt; &gt; &gt; metadata (some of which was enforced to be correct by the co= mpiler)<br> &gt; &gt; &gt; that could be completely ignored if the programmer didn&#39;= t want to use<br> &gt; &gt; &gt; it. Now that D has taken up this syntax, we&#39;ve done almo= st the<br> &gt; &gt; &gt; opposite. is mostly used in situations where it changes th= e compiled<br> &gt; &gt; &gt; code, changes the existing language, =A0and is in no way opt= ional. We<br> &gt; &gt; &gt; don&#39;t really support<br> &gt; &gt;<br> &gt; &gt; user<br> &gt; &gt;<br> &gt; &gt; &gt; defined metadata, and we can&#39;t use what annotations we h= ave as metadata<br> &gt; &gt; &gt; because only the compiler can actually use it. Most of the u= ses I&#39;ve<br> &gt; &gt; &gt; seen seem to be a way to cram more keywords into the languag= e without<br> &gt; &gt; &gt; adding more keywords.<br> &gt; &gt; &gt; I&#39;ve been holding in this sort of rant for a while, but = in summary, my<br> &gt; &gt; &gt; response is that unless the desired use for was defined ra= dically<br> &gt; &gt; &gt; differently by D when it was adopted (and, as far as I can t= ell, it<br> &gt; &gt; &gt; wasn&#39;t), seeing another abuse of it just makes me feel s= lightly sick<br> &gt; &gt; &gt; inside.<br> &gt; &gt;<br> &gt; &gt; As it is, user-defined attributes can be added later using the = syntax.<br> &gt; &gt; True,<br> &gt; &gt; all of the current uses of are for where we decided to save a k= eyword,<br> &gt; &gt; but<br> &gt; &gt; that doesn&#39;t stop user-defined attributes from using the synt= ax later. It<br> &gt; &gt; just<br> &gt; &gt; means that those that are currently defined will always be specia= l.<br> &gt;<br> &gt; This is the difference in philosophy at the core of my general unhappi= ness.<br> &gt; When Java officially added annotations, they were designed and built t= o be<br> &gt; used for user-defined metadata. We added &quot;Property&quot; to the g= rammar,<br> &gt; celebrated that we had them too, then stopped. The result is that we&#= 39;re<br> &gt; throwing around as an excuse for language keywords and boasting abou= t how<br> &gt; we have annotations when, by the definition of any other language, we<= br> &gt; simply don&#39;t.<br> &gt; I guess the best answer from where I&#39;m standing is to start throwi= ng around<br> &gt; possible syntaxes for annotation declarations and references to them i= n<br> &gt; compile-time reflection. I just really hope this gets in to D2, so we<= br> &gt; aren&#39;t permanently stuck with &quot;fake annotations.&quot;<br> <br> </div></div><p>I don&#39;t really see anything wrong with leaving the curre= nt attributes as<br> they are and then just using for user-defined attributes as well. There w= ill<br> just be a set of attribute names which are reserved by the compiler. All th= at<br> using a different syntax for user-defined attributes would buy you would be= <br> that you could use the attribute names that the compiler has reserved - saf= e,<br> trusted, system, and property. And that isn&#39;t exactly a huge gain. We m= ight as<br> well just use for user-defined attributes as well.</p></blockquote><div>= =A0</div><div>My point wasn&#39;t that the syntax should be different (it= =A0should definitely be the same), my point was that we stopped short of fu= lly implementing annotation support and that the result seems to be signifi= cantly less than ideal.</div> <blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi= ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px= ; border-left-style: solid;"><p>=A0</p></blockquote></div> --0016e6d273a8f20be404a54c1574--
Jun 09 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-09 12:01, Andrew Wiley wrote:
 On Thu, Jun 9, 2011 at 1:32 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote:
 On 2011-06-09 01:15, Andrew Wiley wrote:
 On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis

<jmdavisProg gmx.com>wrote:
 On 2011-06-09 00:20, Andrew Wiley wrote:
 On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal
 <alex_dovhal yahoo.com>

wrote:
 There have been several topics discussing UFCS recently. So here
 is one more)
 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:
 void func(Type1 p1, Type2 p2);
 
 and later call it:
 fucn(a, b);  //or
 a.func( _, b);  //or
 b.func(a,  _);
 
 This way Timon Gehr's example:
    take(10,stride(2,cycle([3,2,5,3])));
    [3,2,5,3].cycle().stride(2).take(10);
 
 would be written as this:
    [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);
 
 Which is a little longer. On the other side this way benefits 






  * UFCS is directly seen by both the programmer and compiler;
  * UFCS doesn't mix with member call syntax;
  * UFCS can be used for any type and for any argument, e.g.
  
    a.func( , b) or b.func(a,  );
  
  * UFCS can be used for more than one argument: a.func( _,
   _~[1]);
 
 What do you think?

I find it funny that was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of



the
 rules

for
 annotations is that they cannot directly alter the code the
 compiler outputs. You can add plugins to the Java compiler that
 use



annotations
 to modify the AST before it's compiled, and you can use annotations
 for runtime bytecode generation or interpret them using reflection,
 but if

you
 take unannotated code and annotated code and compile it (without
 altering the compiler), the generated code will not change.
 The idea was to make them a part of the language composed entirely
 of metadata (some of which was enforced to be correct by the
 compiler) that could be completely ignored if the programmer
 didn't want to use it. Now that D has taken up this syntax, we've
 done almost the opposite.   is mostly used in situations where it
 changes the



compiled
 code, changes the existing language,  and is in no way optional. We
 don't really support

user
 defined metadata, and we can't use what annotations we have as



metadata
 because only the compiler can actually use it. Most of the uses
 I've seen seem to be a way to cram more keywords into the language
 without adding more keywords.
 I've been holding in this sort of rant for a while, but in summary,



my
 response is that unless the desired use for   was defined radically
 differently by D when it was adopted (and, as far as I can tell, it
 wasn't), seeing another abuse of it just makes me feel slightly
 sick inside.

As it is, user-defined attributes can be added later using the


syntax.
 True,
 all of the current uses of   are for where we decided to save a


keyword,
 but
 that doesn't stop user-defined attributes from using the syntax
 later.


It
 just
 means that those that are currently defined will always be special.

This is the difference in philosophy at the core of my general

unhappiness.
 When Java officially added annotations, they were designed and built to

be
 used for user-defined metadata. We added "Property" to the grammar,
 celebrated that we had them too, then stopped. The result is that we're
 throwing around   as an excuse for language keywords and boasting about

how
 we have annotations when, by the definition of any other language, we
 simply don't.
 I guess the best answer from where I'm standing is to start throwing

around
 possible syntaxes for annotation declarations and references to them in
 compile-time reflection. I just really hope this gets in to D2, so we
 aren't permanently stuck with "fake annotations."

I don't really see anything wrong with leaving the current attributes as they are and then just using for user-defined attributes as well. There will just be a set of attribute names which are reserved by the compiler. All that using a different syntax for user-defined attributes would buy you would be that you could use the attribute names that the compiler has reserved - safe, trusted, system, and property. And that isn't exactly a huge gain. We might as well just use for user-defined attributes as well.

My point wasn't that the syntax should be different (it should definitely be the same), my point was that we stopped short of fully implementing annotation support and that the result seems to be significantly less than ideal.

Well, adding user-defined attributes would be purely an additive change and wouldn't break any code, so there's probably a decent chance that we'll be able to get it added to D2 at some point. But there are still plenty of more core issues that need to be addressed before we look at adding features like that, so I don't think that it's all that big a deal that we don't have them yet. I think that there's a good chance that we will eventually. - Jonathan M Davis
Jun 09 2011