www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [ ArgumentList ] vs. ( ArgumentList )

reply Walter Bright <newshound2 digitalmars.com> writes:
For User Defined Attributes.

In the north corner we have the current champeeeeon:

-------
[ ArgumentList ]

Pros:
     precedent with C#
     looks nice

Cons:
     not so greppable
     parsing ambiguity with [array literal].func();

------
In the south corner, there's the chaaaaallenger:

 ( ArgumentList )

Pros:
     looks like existing  attribute syntax
     no parsing problems

Cons:
     not as nice looking
------

No hitting below the belt! Let the games begin!
Nov 06 2012
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
  ( ArgumentList )
     not as nice looking

Actually, I find it even nicer looking than the other syntax. Combine it with allowing the omission of the parens for a single argument and allowing multiple specifications of it per declaration, and it starts to look a whole lot like the built-in attributes. David
Nov 06 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 20:18, Walter Bright a écrit :
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
 precedent with C#
 looks nice

 Cons:
 not so greppable
 parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
 looks like existing  attribute syntax
 no parsing problems

Look like what is done in Java, python and PHP.
 Cons:
 not as nice looking
 ------

 No hitting below the belt! Let the games begin!

BTW, I'm all for argument argument argument rather than (argumentlist)
Nov 06 2012
prev sibling next sibling parent "r_m_r" <r_m_r mailinator.com> writes:
 ( ArgumentList ) FTW :D

On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
     precedent with C#
     looks nice

 Cons:
     not so greppable
     parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
     looks like existing  attribute syntax
     no parsing problems

 Cons:
     not as nice looking
 ------

 No hitting below the belt! Let the games begin!

Nov 06 2012
prev sibling next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.11.2012 20:18, schrieb Walter Bright:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

I think ( ArgumentList ) would be more consistent with what D already has, but my vot still goes for [ ArgumentList ] because personally I find that 's make the code look "ugly". There are other languages where the ' ' is only used for language features you shouldn't be using a lot. Kind Regards Benjamin Thaut
Nov 06 2012
prev sibling next sibling parent reply "ponce" <spam spam.org> writes:
I like  (ArgumentList) better for stated reason: it looks like
existing  attributes.
Nov 06 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 20:47, Manu a écrit :
 I actually quite liked Tristan's argument.

 [attr, attr2] feels more like what it is, an annotation. It does
 nothing, has no effect on the declaration on its own.
 the  attr syntax looks like existing attributes, and with that kinda
 comes the presumption that they actually DO something, affect the code
 generated in some way.

This is definitively what they should do at some point.
 For that reason, I buy the argument that [attrs...] being visually
 distinct makes more sense, more like what it is.

 Perhaps it should be termed 'annotation' rather than 'attribute'?


 On 6 November 2012 21:38, ponce <spam spam.org <mailto:spam spam.org>>
 wrote:

     I like  (ArgumentList) better for stated reason: it looks like
     existing  attributes.

Nov 06 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-11-06, 20:18, Walter Bright wrote:

 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

( ArgumentList ). -- Simen
Nov 06 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 [ ArgumentList ]

 Pros:
     precedent with C#

I guess »precedent with Java« should be added to the respective () list then. David
Nov 06 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 20:46, David Nadlinger a écrit :
 On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 [ ArgumentList ]

 Pros:
 precedent with C#

I guess »precedent with Java« should be added to the respective () list then. David

And python. By themselves, they represent a much bigger user base than C#
Nov 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-06 20:18, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

I vote for ( ArgumentList ). If this is syntax chosen I also hope attribute will be legal as well. -- /Jacob Carlborg
Nov 06 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-06 20:52, Manu wrote:
 I'd like to re-enforce the consideration that  attribute() makes it
 looks like they affect the code generation somehow... they're really
 just annotations.

I still like the syntax. -- /Jacob Carlborg
Nov 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-06 20:52, Manu wrote:
 I'd like to re-enforce the consideration that  attribute() makes it
 looks like they affect the code generation somehow... they're really
 just annotations.

Then we just have to make it possible to generate code with these attributes :) -- /Jacob Carlborg
Nov 06 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 21:17, Jacob Carlborg a écrit :
 On 2012-11-06 20:52, Manu wrote:
 I'd like to re-enforce the consideration that  attribute() makes it
 looks like they affect the code generation somehow... they're really
 just annotations.

Then we just have to make it possible to generate code with these attributes :)

That seems the most reasonable option.
Nov 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec5014c7181014304cdd94d30
Content-Type: text/plain; charset=UTF-8

On 6 November 2012 22:01, Jacob Carlborg <doob me.com> wrote:

 On 2012-11-06 20:52, Manu wrote:

 I'd like to re-enforce the consideration that  attribute() makes it
 looks like they affect the code generation somehow... they're really
 just annotations.

I still like the syntax.

I liked it initially too, but reason changed my mind... --bcaec5014c7181014304cdd94d30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6 November 2012 22:01, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"m= ailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><= div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> <div class=3D"im">On 2012-11-06 20:52, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;d like to re-enforce the consideration that attribute() makes it<br> looks like they affect the code generation somehow... they&#39;re really<br=

</blockquote> <br></div> I still like the syntax.</blockquote><div><br></div><div>I liked it initial= ly too, but reason changed my mind...</div></div></div> --bcaec5014c7181014304cdd94d30--
Nov 06 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 6 November 2012 at 19:52:45 UTC, Manu wrote:
 I'd like to re-enforce the consideration that  attribute() 
 makes it looks
 like they affect the code generation somehow... they're really 
 just
 annotations.

Why would look like that to you? Actually, seems to yell »annotation« to me, probably because of my (limited) exposure to Python. And don't forget that UDAs _do_ in practice have an effect on code generation, at least a lot more than safe-ty attributes. Whether the mechanism by which they gain that effect is built into the compiler or implemented in a library doesn't matter to the user of a library. David
Nov 06 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 6 November 2012 at 20:01:27 UTC, Jacob Carlborg wrote:
 On 2012-11-06 20:52, Manu wrote:
 I'd like to re-enforce the consideration that  attribute() 
 makes it
 looks like they affect the code generation somehow... they're 
 really
 just annotations.

I still like the syntax.

I'd also like to add that the OP argument is false. Sure, the attributes themselves are just meta-data and you can use them for purely informative purposes (to annotate with documentation, author names, versions, license, etc..) but more commonly attributes are intended to be introspected on at CT or RT and used to *indirectly cause some processing*. The end result is the same and user defined attributes should be consistent with built-in ones. Syntax wise, I agree the C# version is /slightly/ more pleasant to the eye than the Java one but given the possible grammar ambiguities and the consistency with buit-ins, (attributes) win by a landslide.
Nov 06 2012
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.11.2012 20:52, schrieb Manu:
 I'd like to re-enforce the consideration that  attribute() makes it
 looks like they affect the code generation somehow... they're really
 just annotations.


 On 6 November 2012 21:47, Jacob Carlborg <doob me.com
 <mailto:doob me.com>> wrote:

     On 2012-11-06 20:18, Walter Bright wrote:

         For User Defined Attributes.

         In the north corner we have the current champeeeeon:

         -------
         [ ArgumentList ]

         Pros:
               precedent with C#
               looks nice

         Cons:
               not so greppable
               parsing ambiguity with [array literal].func();

         ------
         In the south corner, there's the chaaaaallenger:

          ( ArgumentList )

         Pros:
               looks like existing  attribute syntax
               no parsing problems

         Cons:
               not as nice looking
         ------

         No hitting below the belt! Let the games begin!


     I vote for  ( ArgumentList ). If this is syntax chosen I also hope
      attribute will be legal as well.

     --
     /Jacob Carlborg

Speaking from C# point of view, the same argument can be used, because in .NET [] attributes might change the way the code gets generated. Some of them like are even reckognized by the JIT/NGEN. -- Paulo
Nov 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b6d93405e5a7704cdd8e03c
Content-Type: text/plain; charset=UTF-8

I actually quite liked Tristan's argument.

[attr, attr2] feels more like what it is, an annotation. It does nothing,
has no effect on the declaration on its own.
the  attr syntax looks like existing attributes, and with that kinda comes
the presumption that they actually DO something, affect the code generated
in some way.
For that reason, I buy the argument that [attrs...] being visually distinct
makes more sense, more like what it is.

Perhaps it should be termed 'annotation' rather than 'attribute'?


On 6 November 2012 21:38, ponce <spam spam.org> wrote:

 I like  (ArgumentList) better for stated reason: it looks like
 existing  attributes.

--047d7b6d93405e5a7704cdd8e03c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I actually quite liked Tristan&#39;s argument.<div><br></div><div>[attr, at= tr2] feels more like what it is, an annotation. It does nothing, has no eff= ect on the declaration on its own.</div><div>the attr syntax looks like ex= isting attributes, and with that kinda comes the presumption that they actu= ally DO something, affect the code generated in some way.</div> <div>For that reason, I buy the argument that [attrs...] being visually dis= tinct makes more sense, more like what it is.</div><div><br></div><div>Perh= aps it should be termed &#39;annotation&#39; rather than &#39;attribute&#39= ;?</div> <div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 6 November= 2012 21:38, ponce <span dir=3D"ltr">&lt;<a href=3D"mailto:spam spam.org" t= arget=3D"_blank">spam spam.org</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> I like (ArgumentList) better for stated reason: it looks like<br> existing attributes.<br> </blockquote></div><br></div> --047d7b6d93405e5a7704cdd8e03c--
Nov 06 2012
prev sibling next sibling parent "Damian" <damianroyday gmail.com> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
     precedent with C#
     looks nice

 Cons:
     not so greppable
     parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
     looks like existing  attribute syntax
     no parsing problems

 Cons:
     not as nice looking
 ------

 No hitting below the belt! Let the games begin!

At first I liked the C# style, but it just does not mix well with D's system attributes. So my vote is for.. ( ArgumentList ) I would prefer if I could enclose system and user attributes in the parenthesis, with no idea how that would work though.
Nov 06 2012
prev sibling next sibling parent "mist" <none none.none> writes:
Vote for " ( ArgumentList )"
Mostly because of current and yet possible ambiguity issue.
Nov 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--f46d043890b994629d04cdd8f1f7
Content-Type: text/plain; charset=UTF-8

I'd like to re-enforce the consideration that  attribute() makes it looks
like they affect the code generation somehow... they're really just
annotations.


On 6 November 2012 21:47, Jacob Carlborg <doob me.com> wrote:

 On 2012-11-06 20:18, Walter Bright wrote:

 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

I vote for ( ArgumentList ). If this is syntax chosen I also hope attribute will be legal as well. -- /Jacob Carlborg

--f46d043890b994629d04cdd8f1f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I&#39;d like to re-enforce the consideration that attribute() makes it loo= ks like they affect the code generation somehow... they&#39;re really just = annotations.<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O= n 6 November 2012 21:47, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"ma= ilto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 2= 012-11-06 20:18, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> For User Defined Attributes.<br> <br> In the north corner we have the current champeeeeon:<br> <br> -------<br> [ ArgumentList ]<br> <br> Pros:<br> =C2=A0 =C2=A0 =C2=A0precedent with C#<br> =C2=A0 =C2=A0 =C2=A0looks nice<br> <br> Cons:<br> =C2=A0 =C2=A0 =C2=A0not so greppable<br> =C2=A0 =C2=A0 =C2=A0parsing ambiguity with [array literal].func();<br> <br> ------<br> In the south corner, there&#39;s the chaaaaallenger:<br> <br> ( ArgumentList )<br> <br> Pros:<br> =C2=A0 =C2=A0 =C2=A0looks like existing attribute syntax<br> =C2=A0 =C2=A0 =C2=A0no parsing problems<br> <br> Cons:<br> =C2=A0 =C2=A0 =C2=A0not as nice looking<br> ------<br> <br> No hitting below the belt! Let the games begin!<br> </blockquote> <br></div></div> I vote for ( ArgumentList ). If this is syntax chosen I also hope attribu= te will be legal as well.<span class=3D"HOEnZb"><font color=3D"#888888"><br=

-- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br></div> --f46d043890b994629d04cdd8f1f7--
Nov 06 2012
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 Cons:
     not so greppable

I'd argue that this is important.
Nov 06 2012
prev sibling next sibling parent reply Faux Amis <faux amis.com> writes:
On 06/11/2012 20:18, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

With [] I expect array operations; can I slice it?
Nov 06 2012
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-11-06, 20:55, Faux Amis wrote:

 On 06/11/2012 20:18, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

With [] I expect array operations; can I slice it?

Of course. It's a typetuple. -- Simen
Nov 06 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 6 November 2012 at 20:13:32 UTC, Manu wrote:
 this is a really good point. they are a tuple, you can slice 
 it, iterate
 it...
 further supports [] to my mind ;)

Not really – [] represents an array, not a tuple. David
Nov 06 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/6/12, Walter Bright <newshound2 digitalmars.com> wrote:
  ( ArgumentList )

I vote for . We have both arrays, static arrays, and hashes which use the [] syntax. And we have a precedent for with property functions and other attributes (e.g. disable).
Nov 06 2012
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
     precedent with C#
     looks nice

 Cons:
     not so greppable
     parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
     looks like existing  attribute syntax
     no parsing problems

 Cons:
     not as nice looking
 ------

 No hitting below the belt! Let the games begin!

() with optional ().
Nov 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf307811d0ea506404cdd93b59
Content-Type: text/plain; charset=UTF-8

On 6 November 2012 21:55, Faux Amis <faux amis.com> wrote:

 On 06/11/2012 20:18, Walter Bright wrote:

 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

With [] I expect array operations; can I slice it?

this is a really good point. they are a tuple, you can slice it, iterate it... further supports [] to my mind ;) --20cf307811d0ea506404cdd93b59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra">On 6 November 2012 21:55, Faux Amis <span dir=3D= "ltr">&lt;<a href=3D"mailto:faux amis.com" target=3D"_blank">faux amis.com<= /a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5">On 06/11/2012 20:18, Walter Bright wrote:= <br> <blockquote 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;p= adding-left:1ex"> For User Defined Attributes.<br> <br> In the north corner we have the current champeeeeon:<br> <br> -------<br> [ ArgumentList ]<br> <br> Pros:<br> =C2=A0 =C2=A0 =C2=A0precedent with C#<br> =C2=A0 =C2=A0 =C2=A0looks nice<br> <br> Cons:<br> =C2=A0 =C2=A0 =C2=A0not so greppable<br> =C2=A0 =C2=A0 =C2=A0parsing ambiguity with [array literal].func();<br> <br> ------<br> In the south corner, there&#39;s the chaaaaallenger:<br> <br> ( ArgumentList )<br> <br> Pros:<br> =C2=A0 =C2=A0 =C2=A0looks like existing attribute syntax<br> =C2=A0 =C2=A0 =C2=A0no parsing problems<br> <br> Cons:<br> =C2=A0 =C2=A0 =C2=A0not as nice looking<br> ------<br> <br> No hitting below the belt! Let the games begin!<br> </blockquote> <br></div></div> With [] I expect array operations; can I slice it?<br></blockquote><div>=C2= =A0</div></div>this is a really good point. they are a tuple, you can slice= it, iterate it...</div><div class=3D"gmail_extra">further supports [] to m= y mind ;)</div> --20cf307811d0ea506404cdd93b59--
Nov 06 2012
prev sibling next sibling parent Matt Soucy <msoucy csh.rit.edu> writes:
On 11/06/2012 02:18 PM, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

One more vote for ( ArgumentList ) with optional () for simple ones - they seem like they would fit with the rest of the language much more nicely
Nov 06 2012
prev sibling next sibling parent captaindet <2krnk gmx.net> writes:
 ( ArgumentList ) is the winner for me.


On 2012-11-06 13:18, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
 precedent with C#
 looks nice

 Cons:
 not so greppable
 parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
 looks like existing  attribute syntax
 no parsing problems

 Cons:
 not as nice looking
 ------

 No hitting below the belt! Let the games begin!

Nov 06 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
I vote for  (ArgumentList).

Or  Arg1  Arg2 ... as somebody mentioned.

It's more consistent with existing  -syntax.  Reusing [] is bad because
it visually conflicts with array literals (and makes parsing harder to
boot).   is a unique symbol that, so far, is associated with attributes,
so it makes sense to use it also to mark user-defined attributes.

I don't buy the argument that other languages have a different syntax.
We're talking about D here, and what is chosen should make sense in the
context of D, without undue influence from other languages.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Nov 06 2012
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
I agree with David and deadalnix agument wise, so:

 (attriblist) or  attrib1  attrib2

with the hope that this syntax is extensible enough to make it possible
to implement something like  safe or  noheap as library functionality at
some day.
Nov 06 2012
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/06/2012 11:18 AM, Walter Bright wrote:
 For User Defined Attributes.

() with optional (). Ali
Nov 06 2012
prev sibling next sibling parent reply "Tavi Cacina" <octavian.cacina outlook.com> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Nov 06 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 22:07, Tavi Cacina a écrit :
 On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 No hitting below the belt! Let the games begin!


Who will make that even shorter ?
Nov 06 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/06/2012 01:19 PM, deadalnix wrote:
 Le 06/11/2012 22:07, Tavi Cacina a écrit :
 On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 No hitting below the belt! Let the games begin!


Who will make that even shorter ?

Not shorter but definitely more in line with C and C++ heritage: static() with optional () Ali
Nov 06 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2012 1:07 PM, Tavi Cacina wrote:
 On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 No hitting below the belt! Let the games begin!


2 penalty points for that one!
Nov 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-06 22:38, Walter Bright wrote:
 On 11/6/2012 1:07 PM, Tavi Cacina wrote:
 On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 No hitting below the belt! Let the games begin!


2 penalty points for that one!

The ( ArgumentList ) syntax still wins :) -- /Jacob Carlborg
Nov 07 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added. - Jonathan M Davis
Nov 06 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 22:02, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

Can you explain that code breakage ?
Nov 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2012 1:41 PM, deadalnix wrote:
 Le 06/11/2012 22:02, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

Can you explain that code breakage ?

C++11 has had problems adding new keywords, as about every identifier somewhere has been used by someone's C++ source code, and they don't want to break existing code. So C++11 winds up with awful things like "decltype".
Nov 06 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 22:53, Walter Bright a écrit :
 On 11/6/2012 1:41 PM, deadalnix wrote:
 Le 06/11/2012 22:02, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

Can you explain that code breakage ?

C++11 has had problems adding new keywords, as about every identifier somewhere has been used by someone's C++ source code, and they don't want to break existing code. So C++11 winds up with awful things like "decltype".

OK I understand. This is fixable easily by adding thoses magic attribute in object and using regular lookup rules.
Nov 06 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 00:29, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 23:26:28 deadalnix wrote:
 Le 06/11/2012 22:53, Walter Bright a écrit :
 On 11/6/2012 1:41 PM, deadalnix wrote:
 Le 06/11/2012 22:02, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

Can you explain that code breakage ?

C++11 has had problems adding new keywords, as about every identifier somewhere has been used by someone's C++ source code, and they don't want to break existing code. So C++11 winds up with awful things like "decltype".

OK I understand. This is fixable easily by adding thoses magic attribute in object and using regular lookup rules.

It would still break code, because then there would be a conflict which would have to be resolved. It's the same as if we were to do something like add a function to std.file called find. Anything importing both std.algorithm and std.file would break (assuming that the arguments matched both). To some extent, this is unavoidable. Adding _any_ function to a library risks breaking user code if there's any other function that it uses which has the same name and similar enough arguments. That's what we get for automatically inferring which function and requiring the full path for disambiguation rather than requiring the full path unless a specific command makes it so that it's unnecessary (e.g. aliasing std.algorithm.find to find). So, if we want to avoid breaking code when adding new built-in attributes, we're going to have to define custom attributes in a way which they can't ever conflict with built-in ones - which would probably mean making customAttribute illegal and require (customAttribute). But if we're willing to break user code when adding a new attribute, forcing user code to change its attribute names or give their full path, then we can allow customAttribute. - Jonathan M Davis

As you stated, this is true for ANY identifier, so I don't see why this pop in this particular discussion.
Nov 06 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, November 06, 2012 23:26:28 deadalnix wrote:
 Le 06/11/2012 22:53, Walter Bright a écrit :
 On 11/6/2012 1:41 PM, deadalnix wrote:
 Le 06/11/2012 22:02, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

Can you explain that code breakage ?

C++11 has had problems adding new keywords, as about every identifier somewhere has been used by someone's C++ source code, and they don't want to break existing code. So C++11 winds up with awful things like "decltype".

OK I understand. This is fixable easily by adding thoses magic attribute in object and using regular lookup rules.

It would still break code, because then there would be a conflict which would have to be resolved. It's the same as if we were to do something like add a function to std.file called find. Anything importing both std.algorithm and std.file would break (assuming that the arguments matched both). To some extent, this is unavoidable. Adding _any_ function to a library risks breaking user code if there's any other function that it uses which has the same name and similar enough arguments. That's what we get for automatically inferring which function and requiring the full path for disambiguation rather than requiring the full path unless a specific command makes it so that it's unnecessary (e.g. aliasing std.algorithm.find to find). So, if we want to avoid breaking code when adding new built-in attributes, we're going to have to define custom attributes in a way which they can't ever conflict with built-in ones - which would probably mean making customAttribute illegal and require (customAttribute). But if we're willing to break user code when adding a new attribute, forcing user code to change its attribute names or give their full path, then we can allow customAttribute. - Jonathan M Davis
Nov 06 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/7/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 It would still break code, because then there would be a conflict which
 would have to be resolved.

I really doubt we're going to create any new language properties (you're the only one I can see suggesting this). And if we are, we should use special identifiers that begin with underscores. In any case, we can always use an alias to resolve conflicts.
Nov 06 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/7/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 11/7/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 It would still break code, because then there would be a conflict which
 would have to be resolved.

I really doubt we're going to create any new language properties (you're the only one I can see suggesting this). And if we are, we should use special identifiers that begin with underscores. In any case, we can always use an alias to resolve conflicts.

Actually, let me give you a better argument. Let's say you implement your own (NoGC) attribute that you use in your own library. You use it like so: (NoGC) class Foo { } And somewhere down the road 5 months from now druntime introduces it's own NoGC attribute. Personally I would rather have a compile-time error due to clashing symbol names right then and there. Otherwise I could easily end up in a situation where I **forget** to parenthesize my custom NoGC attribute and end up using the druntime one: (NoGC) class Foo { } NoGC class Bar { } // oops, I meant (NoGC) I really don't think we should have parenthesis dictate name lookup, it's way too easy to screw things up like that. Let the symbols clash so I can fix the problem with the already existing alias tools in D: alias mymod.NoGC MyNoGC; (MyNoGC) class Foo { } MyNoGC class Bar { } or simply: (mymod.NoGC) class Foo { } mymod.NoGC class Bar { } Then I can be at ease knowing I'm not accidentally using one attribute or the other because of an issue with missing parens.
Nov 06 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-06 22:53, Walter Bright wrote:

 C++11 has had problems adding new keywords, as about every identifier
 somewhere has been used by someone's C++ source code, and they don't
 want to break existing code. So C++11 winds up with awful things like
 "decltype".

Just create a new attribute, call it "builtin" or something similar, which takes attributes as arguments, i.e. builtin(shared) int a; builtin(property) int b; I'm not suggesting that we should change the existing shared and property, I just used them as an example. -- /Jacob Carlborg
Nov 07 2012
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 No hitting below the belt! Let the games begin!

If those are our only choices, then I vote for ( ArgumentList ). Otherwise, I think these look better: [: ArgumentList :] or |: ArgumentList :|
Nov 06 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2012 1:26 PM, Caligo wrote:
 On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 No hitting below the belt! Let the games begin!

If those are our only choices, then I vote for ( ArgumentList ). Otherwise, I think these look better: [: ArgumentList :] or |: ArgumentList :|

:-)
Nov 06 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/06/2012 01:39 PM, Walter Bright wrote:
 On 11/6/2012 1:26 PM, Caligo wrote:
 On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 No hitting below the belt! Let the games begin!

If those are our only choices, then I vote for ( ArgumentList ). Otherwise, I think these look better: [: ArgumentList :] or |: ArgumentList :|

:-)

More explicitly: (-: ArgumentList :-) Ali
Nov 06 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-06 22:26, Caligo wrote:

 If those are our only choices, then I vote for  ( ArgumentList ).

 Otherwise, I think these look better:

 [: ArgumentList :]

 or

 |: ArgumentList :|

These are just horrible. -- /Jacob Carlborg
Nov 07 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 09:37, Jacob Carlborg a crit :
 On 2012-11-06 22:26, Caligo wrote:

 If those are our only choices, then I vote for  ( ArgumentList ).

 Otherwise, I think these look better:

 [: ArgumentList :]

 or

 |: ArgumentList :|

These are just horrible.

I think that was joke :D
Nov 07 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 14:36, deadalnix wrote:

 I think that was joke :D

You never can be too certain when it comes to syntax suggestions :) -- /Jacob Carlborg
Nov 07 2012
prev sibling next sibling parent "Tavi Cacina" <octavian.cacina outlook.com> writes:
I must add that watching the mind game from Chris 
http://forum.dlang.org/post/puseurlcwbgvigwkdowu forum.dlang.org 
the [] is quite appealing. The   is perfect if one needs just a 
singular  tag. Is having both not an option :-)
Nov 06 2012
prev sibling next sibling parent "alex" <info alexanderbothe.com> writes:
 
Nov 06 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Nov 06, 2012 at 03:26:53PM -0600, Caligo wrote:
 On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 No hitting below the belt! Let the games begin!

If those are our only choices, then I vote for ( ArgumentList ). Otherwise, I think these look better: [: ArgumentList :] or |: ArgumentList :|

They look like smileys to me. To me, they look worse than Arg. T -- Once bitten, twice cry...
Nov 06 2012
prev sibling next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 11/06/12 22:02, Jonathan M Davis wrote:
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

Easy - do not introduce any new *global* built-in attributes, ever. There's no reason why they all can't use the same look-up rules. As to the syntax - it doesn't matter, as long as it isn't "[ArgumentList]" as that one is ambiguous (from a programmer POV, even if the compiler could deal with it - which i'm not convinced is the case here, considering all contexts where attributes have to be allowed and the inevitable evolution of this feature). " [ArgumentList]". artur
Nov 06 2012
next sibling parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote
 On Wed, 07 Nov 2012 15:51:50 -0000, Nick Sabalausky 
 <SeeWebsiteToContactMe semitwist.com> wrote:

 On Tue, 06 Nov 2012 22:53:36 +0100
 Artur Skawina <art.08.09 gmail.com> wrote:
 " [ArgumentList]".

vote++ It has all the benefits of ' (...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

I hadn't replied to this thread earlier because I didn't have a strong opinion either way, but, this suggestion appears to be the best of both worlds. So.. vote++

+1
Nov 07 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-07 16:51, Nick Sabalausky wrote:

 vote++

 It has all the benefits of ' (...)' (which are very compelling on
 their own), but also has the *ONE* benefit of '[...]': Much less
 getting lost in stupid parenthesis, as demonstrated here:
 http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases -- /Jacob Carlborg
Nov 07 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 19:44, Tobias Pankrath a écrit :
 Second: When the time comes, we'll hopefully have enough reengineering
 tools that can fully qualify any conflicting uses of a name automatically.

As long as SURPRISE feature are added to master, that is not gonna happen.
Nov 07 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, November 06, 2012 22:53:36 Artur Skawina wrote:
 On 11/06/12 22:02, Jonathan M Davis wrote:
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

no reason why they all can't use the same look-up rules.

That's not really acceptable IMHO. Not being able to add new attributes to the language itself in the future is way too restrictive, and I expect that we'll come up with more that we want to add eventually. Designing custom attributes in a way that is guaranteed to conflict with that is a bad idea. We're restricting ourselves and causing problems for ourselves later when we could easily avoid doing so. - Jonathan M Davis
Nov 06 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 00:21, Jonathan M Davis a écrit :
 On Tuesday, November 06, 2012 22:53:36 Artur Skawina wrote:
 On 11/06/12 22:02, Jonathan M Davis wrote:
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

no reason why they all can't use the same look-up rules.

That's not really acceptable IMHO. Not being able to add new attributes to the language itself in the future is way too restrictive, and I expect that we'll come up with more that we want to add eventually. Designing custom attributes in a way that is guaranteed to conflict with that is a bad idea. We're restricting ourselves and causing problems for ourselves later when we could easily avoid doing so. - Jonathan M Davis

Language attribute can be added in object.d and regular lookup rule apply.
Nov 06 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 6 November 2012 at 23:23:47 UTC, Jonathan M Davis 
wrote:
 Designing custom attributes
 in a way that is guaranteed to conflict with that is a bad idea.

Well, the same could be said about language keywords as well, or really just adding names in general. I don't see a good reason why special contortions for user defined annotations should be required, if simply adding a name to Phobos (even a private one!) can have just the same effect. David
Nov 06 2012
prev sibling next sibling parent reply kraybourne <stdin kraybourne.com> writes:
 (Attr...) and  attr1  attr2


Because I secretly dream about stuff like:

	alias  (nothrow,safe,memoizable)  memosafe;
	 memosafe int foo(){...}
Nov 06 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/7/12 2:27 AM, kraybourne wrote:
  (Attr...) and  attr1  attr2


 Because I secretly dream about stuff like:

 alias  (nothrow,safe,memoizable)  memosafe;

Sure you mean alias memosafe = (nothrow,safe,memoizable); Andrei
Nov 06 2012
parent kraybourne <stdin kraybourne.com> writes:
On 11/7/12 03:48 , Andrei Alexandrescu wrote:
 Sure you mean

 alias  memosafe =  (nothrow,safe,memoizable);


 Andrei

Mind = blown :)
Nov 07 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Tuesday, 6 November 2012 at 19:47:57 UTC, Manu wrote:
 I actually quite liked Tristan's argument.

 [attr, attr2] feels more like what it is, an annotation. It 
 does nothing,
 has no effect on the declaration on its own.
 the  attr syntax looks like existing attributes, and with that 
 kinda comes
 the presumption that they actually DO something, affect the 
 code generated
 in some way.
 For that reason, I buy the argument that [attrs...] being 
 visually distinct
 makes more sense, more like what it is.

 Perhaps it should be termed 'annotation' rather than 
 'attribute'?


 On 6 November 2012 21:38, ponce <spam spam.org> wrote:

 I like  (ArgumentList) better for stated reason: it looks like
 existing  attributes.


If you want, you can take some history into consideration. This DIP is the reason for the property/ safe syntax http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Maybe not that specific page, but it comes from the big annotation discussions.
Nov 06 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, November 07, 2012 00:58:47 Andrej Mitrovic wrote:
 Actually, let me give you a better argument.
 
 Let's say you implement your own  (NoGC) attribute that you use in
 your own library. You use it like so:
 
  (NoGC) class Foo { }
 
 And somewhere down the road 5 months from now druntime introduces it's
 own  NoGC attribute. Personally I would rather have a compile-time
 error due to clashing symbol names right then and there. Otherwise I
 could easily end up in a situation where I **forget** to parenthesize
 my custom NoGC attribute and end up using the druntime one:

That seems like a pretty good argument. - Jonathan M Davis
Nov 06 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, November 07, 2012 02:07:53 deadalnix wrote:
 As you stated, this is true for ANY identifier, so I don't see why this
 pop in this particular discussion.

Because it sucks, and being able to avoid having that problem spread is a good thing. Just because something is a problem in one place doesn't mean that it's okay to have that same problem somewhere else. - Jonathan M Davis
Nov 06 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 11/07/12 00:21, Jonathan M Davis wrote:
 On Tuesday, November 06, 2012 22:53:36 Artur Skawina wrote:
 On 11/06/12 22:02, Jonathan M Davis wrote:
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and it matches what we're already doing for attributes. I also think that's what pretty much everyone was figuring would be used for user-defined attributes. The only major problem would be if ArgumentList is allowed when there's only a single argument, then code could break when new built-in attributes are added.

no reason why they all can't use the same look-up rules.

That's not really acceptable IMHO. Not being able to add new attributes to the language itself in the future is way too restrictive, and I expect that we'll come up with more that we want to add eventually. Designing custom attributes in a way that is guaranteed to conflict with that is a bad idea. We're restricting ourselves and causing problems for ourselves later when we could easily avoid doing so.

What I'm saying is that any new "built-in" attributes (and there *will* be many of these) can have their own namespace. Yeah, it could make the code a little more verbose, but it makes several problems go away. Eg import attr = core.attr; // Could be implicit, ie in object.d. int f() [attr.pure, attr.deprecated("Use something else"), attr.inline] {return 42;} I said attr.pure, but migrating the existing built-ins is not worth the cost, at least not until other language changes happen. The above is too verbose? Then int f() attr[pure, deprecated("Use something else"), inline] {return 42;} is possible (which works just as the above - looks for the named attributes in the "attr" scope). Almost as terse as the current approach, but more powerful. And not as bad as context sensitive keywords (which would be another way to reduce collisions with other user-defined identifiers w/o resorting to pragmas, strings, etc). artur
Nov 06 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 No hitting below the belt! Let the games begin!

I think that [] is sufficiently distinct from built-in attributes, unlike (), but sadly, there's no nice way to parse it at statement scope. There are in fact a couple of ambiguous cases in the parser already; let's not introduce any more, lest we lose the ability to call D easy to parse. (foo) looks too similar to built-in attributes. And let's face it; these annotations are actually quite different (I too prefer the more accurate name, 'annotations') from built-in attributes, the former cannot replace the latter any time soon. I want to hear what people think about [] at declaration scope and [] at statement scope. Too complicated to remember?
Nov 06 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 7 November 2012 at 05:53:35 UTC, Jakob Ovrum wrote:
 I want to hear what people think about [] at declaration scope 
 and  [] at statement scope. Too complicated to remember?

This is quite bad for a variety of reasons, I'll change my vote for purely having [] then.
Nov 06 2012
prev sibling next sibling parent reply "John Chapman" <johnch_atms hotmail.com> writes:
 [ ArgumentList ]

 Pros:
     precedent with C#

And Delphi.
  ( ArgumentList )

 Pros:
     looks like existing  attribute syntax
     no parsing problems

 Cons:
     not as nice looking

ArgumentList makes me think I'm on Twitter. #joke Personally, I also like <ArgumentList>. Prior to property and family being introduced, I'd have gone with [ArgumentList]. But since is the prefix for attributes in D, let's stick with it for UDAs. And as to any clashes between UDAs and possible future built-in ones, I'd say the language has first dibs on names and it's up to people writing UDAs to avoid using names that sound like language constructs.
Nov 07 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/07/2012 09:28 AM, Simen Kjaeraas wrote:
 On 2012-19-07 09:11, John Chapman <johnch_atms hotmail.com> wrote:

 Personally, I also like <ArgumentList>.

I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)>

This example does not show that they cause problems.
Nov 07 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 2:12 AM, Timon Gehr wrote:
 On 11/07/2012 09:28 AM, Simen Kjaeraas wrote:
 On 2012-19-07 09:11, John Chapman <johnch_atms hotmail.com> wrote:

 Personally, I also like <ArgumentList>.

I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)>

This example does not show that they cause problems.

< 3, 4>7 > does.
Nov 07 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 1:30 PM, Simen Kjaeraas wrote:
 I think that's the first time I've heard someone suggest something be
 borrowed from VB. :p

Of course we all take it for granted that Basic sux and does everything wrong, and this has been going on for 30+ years. But in one of the early design sessions on D, I'd ask "Since Basic sux, why is its string handling so nice & convenient, and C's string handling is such a misery?" So Basic did provide some motivation.
Nov 07 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 10:32 PM, Nick Sabalausky wrote:
 On Wed, 07 Nov 2012 14:40:33 -0800
 Walter Bright <newshound2 digitalmars.com> wrote:
 Of course we all take it for granted that Basic sux and does
 everything wrong,

Which Basic? ;) (<-- Just as one example)

All of them!
Nov 07 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-19-07 09:11, John Chapman <johnch_atms hotmail.com> wrote:

 Personally, I also like <ArgumentList>.

I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)> -- Simen
Nov 07 2012
prev sibling next sibling parent reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
On 11/06/2012 10:18 AM, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

[], because should be reserved for future language keywords. Whenever people post suggested language features that require some marking, they introduce a new attribute, because introducing a plain keyword breaks code. If you have UDAs, this further limits language expansion. Example: let's say you want to introduce a "nogc" mark: 1. Not a nogc keyword, that could break "bool nogc;" 2. If you have , nogc could break an "enum nogc;" attribute. 3. Now you're stuck with __nogc or #nogc or something uglier. There is a familiar-to-other-langauges advantage to , but there is a better-than-other-languages advantage to []. My thoughts, NMS
Nov 07 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 09:32, Nathan M. Swan a écrit :
 On 11/06/2012 10:18 AM, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
 precedent with C#
 looks nice

 Cons:
 not so greppable
 parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
 looks like existing  attribute syntax
 no parsing problems

 Cons:
 not as nice looking
 ------

 No hitting below the belt! Let the games begin!

[], because should be reserved for future language keywords. Whenever people post suggested language features that require some marking, they introduce a new attribute, because introducing a plain keyword breaks code. If you have UDAs, this further limits language expansion. Example: let's say you want to introduce a "nogc" mark: 1. Not a nogc keyword, that could break "bool nogc;" 2. If you have , nogc could break an "enum nogc;" attribute. 3. Now you're stuck with __nogc or #nogc or something uglier. There is a familiar-to-other-langauges advantage to , but there is a better-than-other-languages advantage to []. My thoughts, NMS

I think D has already too many feature, and that many of them can be implemented as attribute + AST processing. D should work toward getting this AST stuff and stop adding new keywords all the time.
Nov 07 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-07 14:40, deadalnix wrote:

 I think D has already too many feature, and that many of them can be
 implemented as attribute + AST processing.

 D should work toward getting this AST stuff and stop adding new keywords
 all the time.

I completely agree. -- /Jacob Carlborg
Nov 07 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-08 04:34, Marco Leise wrote:

 Which features are that? It would likely require a major
 rewrite of many routines. Who would want to go through all
 that and the following wave of bugs - some of which may have
 already occurred in the past.

 foreach and scope(...) lowerings are essentially AST
 operations. Are there other D features you would implement as
 AST processing, maybe a link to an earlier post ?

"synchronized" is another that I think would be easy to do with AST macros. Perhaps "with". It's probably not worth replacing existing language features with macros just for the sake of it. But for future features AST macros could perhaps be used instead.
 How close is Rust currently to offering flexible AST
 manipulation for lowerings/attributes/macros, does anyone
 know ?

I have no idea. I haven't looked at Rust in this area. -- /Jacob Carlborg
Nov 08 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/7/2012 5:40 PM, deadalnix пишет:
[snip]
 [], because   should be reserved for future language keywords.

 Whenever people post suggested language features that require some
 marking, they introduce a new  attribute, because introducing a plain
 keyword breaks code. If you have  UDAs, this further limits language
 expansion.

 Example: let's say you want to introduce a "nogc" mark:
 1. Not a nogc keyword, that could break "bool nogc;"
 2. If you have  ,  nogc could break an "enum nogc;" attribute.
 3. Now you're stuck with __nogc or #nogc or something uglier.

 There is a familiar-to-other-langauges advantage to  , but there is a
 better-than-other-languages advantage to [].

 My thoughts,
 NMS

I think D has already too many feature, and that many of them can be implemented as attribute + AST processing.

+1
 D should work toward getting this AST stuff and stop adding new keywords
 all the time.

-- Dmitry Olshansky
Nov 08 2012
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/8/2012 11:34 PM, Nick Sabalausky пишет:
 On Thu, 8 Nov 2012 14:27:14 -0500
 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 [...]Plus, I would imagine
 that library-implemented features would be slower to compile (simply
 because it's just that much more to be compiled).

Also, these particular sorts of things (compile time processing of things that are in-library) essentially amount to executing interpreted code to compile. Sure, that's very powerful, and very well worth having, but should it really be done for very common features? For common features, I'd imagine native non-"interpreted" support would help compilation speed, which is one of D's major goals and benefits. Suddenly interpreting large parts of the language might work against that.

If we finally get to the usual byte-code interpreter then it is more the sufficiently fast to do trivial re-writes that features like synchronized are all about. Anyway I'm not for trying to redo all (if any) of the built-in stuff. If it's bug free and works, fine let it be. We can't remove it anyway. I just anticipate a couple more features to crop up if UDA dropping from nowhere is any indicator. And then another tiny most useful thing, and another one, and ...
 Not that I'm necessarily saying "Always stuff everything into the
 language forever!" I just don't see it as quite so clear-cut.


-- Dmitry Olshansky
Nov 08 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 08/11/2012 20:27, Nick Sabalausky a écrit :
 On Thu, 08 Nov 2012 21:53:11 +0400
 Dmitry Olshansky<dmitry.olsh gmail.com>  wrote:

 11/7/2012 5:40 PM, deadalnix пишет:
 I think D has already too many feature, and that many of them can be
 implemented as attribute + AST processing.

+1

Doesn't that still amount to the same amount of features though? At least from the user's standpoint anyway. Plus, I would imagine that library-implemented features would be slower to compile (simply because it's just that much more to be compiled). Not that I'm necessarily saying "Always stuff everything into the language forever!" I just don't see it as quite so clear-cut.

It have several advantages. It is easy to test a feature as a lib, and then include it later in the standard lib if it does make sense. This is a great improvement as it don't require hacking the compiler. This allow many people to play around with the feature they like without breaking the language in many pieces. As before, successful features can be included. Implementing a feature don't require anymore to know the compiler internal, and do not require either to know other feature internals. A new feature in compiler A is available in other compiler as well at the same time. Same goes for tooling around the language. Now, it is almost impossible to provide proper tooling around D because new feature are dropped into dmd master quite often and all tools have to be updated (most people give up at some point). As of speed, some people, including me but I'm not the only one, are working toward JIT compile for CTFE. With some bytecode caching, I'm pretty sure really good performance can be achieved (unless the feature's implementation suck badly).
Nov 09 2012
prev sibling next sibling parent reply "Jonas Drewsen" <nospam4321 hotmail.com> writes:
My vote goes to  (a,b,c) and  a  b  c.

I never understood why some builtin storage class keywords have   
in front of them (e.g.  property,  safe,  disable) and some don't 
(e.g. pure, nothrow).

IMHO the cleanest design would be to have builtins as plain 
keywords (ie. no   in front). And then  xxx is reserved for UDA.

I understand that this would be a breaking change and not likely 
to happen - just want to know the reasoning behind it.

/Jonas
Nov 07 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 10:22, Jonathan M Davis wrote:

 It mainly came down to not wanting to add new keywords. By using  safe instead
 of safe, safe could still be used as a variable or function or whatnot. There
 was some discussion of which should have   on them on which not (e.g. nothrow
 vs  nothrow was debated), but the decision was fairly arbitrary. If anything
 though, had we not cared about breaking code or whether D looked similar to
 other languages, we probably would have made _all_ attributes start with  
 (including stuff like  public). It would have been wonderfully consistent that
 way, but it wasn't ultimately deemed a good idea.

And then we would suddenly have Objective-C :( -- /Jacob Carlborg
Nov 07 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be a
reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.
Nov 07 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 21:24, Walter Bright a écrit :
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

As a cross topic answer, I'll mention that allowing anything to be an attribute is likely to be a bad idea, and that way to solve that are already discussed.
Nov 07 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments. Andrei
Nov 07 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 4:03 PM, Andrei Alexandrescu wrote:
 On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

Consider that if we do that, then someone will need to disambiguate with: object.safe which is ambiguous: a.b .c x = 3; or is it: a .b.c x = 3; ? Another problem is it pushes off recognition of safe from the parser to the semantic analyzer. This has unknown forward reference complications.
Nov 07 2012
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 08.11.2012 02:48, schrieb Walter Bright:
 On 11/7/2012 4:03 PM, Andrei Alexandrescu wrote:
 On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

Consider that if we do that, then someone will need to disambiguate with: object.safe which is ambiguous: a.b .c x = 3; or is it: a .b.c x = 3; ? Another problem is it pushes off recognition of safe from the parser to the semantic analyzer. This has unknown forward reference complications.

In that case $(object.safe) would be required - the shortcut then only works for simple identifiers and would error out going with the second option ("object is not an attribute" or something). Templates basically have the same ambiguity: A!x.y.z
Nov 08 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-08 02:48, Walter Bright wrote:

 Consider that if we do that, then someone will need to disambiguate with:

      object.safe

 which is ambiguous:

      a.b .c x = 3;

 or is it:

      a .b.c x = 3;

 ?

I would say: a.b .c x = 3; I mean, we read left to right, at least with source code. But as Sönke said, that could require parentheses: (a.b) .c x = 3;
 Another problem is it pushes off recognition of  safe from the parser to
 the semantic analyzer. This has unknown forward reference complications.

Just make it a keyword? The current attributes are already keywords from a user/developer point of view. -- /Jacob Carlborg
Nov 08 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 08/11/2012 02:48, Walter Bright a écrit :
 On 11/7/2012 4:03 PM, Andrei Alexandrescu wrote:
 On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

Consider that if we do that, then someone will need to disambiguate with: object.safe which is ambiguous: a.b .c x = 3; or is it: a .b.c x = 3; ? Another problem is it pushes off recognition of safe from the parser to the semantic analyzer. This has unknown forward reference complications.

How didn't see that coming. I never was a big fan of .identifier syntax for module level stuff. However, you example isn't quite correct. Attributes are for symbols, and your example don't create any new symbol. Let's consider a.b .c d = 3; Now, we have several option to disambiguate that. The first, obvious one is to use () : (a.b) .c d = 3; . When not using (), the compiler understand this as (a.b.c) d = 3; which is an error. Another option is to use auto : a.b auto d = .c(3); Anyway, I don't expect this to break too much code, if any.
Nov 09 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 08/11/2012 01:14, Andrej Mitrovic a crit :
 On 11/8/12, David Nadlinger<see klickverbot.at>  wrote:
 On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu
 wrote:
 "nothrow" isn't actually an  attribute. So much for the value of
 consistency :o)

Another classic inconsistency: disable and deprecated Not only that but I keep writing the former as disabled and get CT errors.

Good new for you, with the given proposal, you'll be able to do alias deprecate deprecated;
Nov 09 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 08/11/2012 12:01, Jonas Drewsen a écrit :
 On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu wrote:
 On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

The original argument that the in front of safe is a way to prevent introducing new keywords is all gone then since "safe" becomes a normal symbol which is reserved in the library and in the compiler to let it do its magic. Then safe could just as well be a normal builtin storage class called "safe". * Plopping types "safe","nothrow" etc. into object.di would be a breaking change. * Making safe, nothrow into keywords called "safe", "nothrow" would be breaking change. The latter would be the cleanest cut and not have the semantic/parse stage problems that Walter mentioned. Another option would to enforce parenthesis (safe) for UDA which would make it less nice for the eyes to look at. /Jonas

nothrow is already a keyword (which is really inconsistent). I'm not sure what it does buy us, and both safe and nothrow are good candidates for lib implementation rather than compiler support.
Nov 09 2012
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 10.11.2012 11:21, schrieb Marco Leise:
 Am Fri, 09 Nov 2012 15:28:40 +0100
 schrieb deadalnix <deadalnix gmail.com>:
 
 nothrow is already a keyword (which is really inconsistent). I'm not 
 sure what it does buy us, and both safe and nothrow are good candidates 
 for lib implementation rather than compiler support.

That requires that the compiler exposes all sorts of statistical data for every statement. E.g. to check if nothrow is violated you have to find statements that throw something and then check if there is a catch block around that, that catches it. If a statement is a function call, you would ask the compiler if that function throws. (In particular if it is a templated function with deduced 'nothrow' and ' safe'). And there you are at the point that you just duplicated the compiler code in the library.

Not duplicated, but moved - which results in a simpler compiler implementation, definitely a good thing. Of course those AST analytics/maccro functionality has to be added in return, but since this has a much broader scope and would make other features (string mixins) obsolete, even that is not quite clear in terms of weight as a counter argument. Anyway, I surely wouldn't expect this to happen anytime soon, but keeping this path open seems like a wise decision - it's a great opportunity to remove/not add features from/to the language without trading functinality or even syntax.
Nov 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 20:40, Jonas Drewsen wrote:

 I we were to allow for  foobar style UDA then "safe" would have to be a
 reserved keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

The current attributes are keywords from a user/developer point view. -- /Jacob Carlborg
Nov 08 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 07, 2012 10:13:47 Jonas Drewsen wrote:
 My vote goes to  (a,b,c) and  a  b  c.
 
 I never understood why some builtin storage class keywords have  
 in front of them (e.g.  property,  safe,  disable) and some don't
 (e.g. pure, nothrow).
 
 IMHO the cleanest design would be to have builtins as plain
 keywords (ie. no   in front). And then  xxx is reserved for UDA.
 
 I understand that this would be a breaking change and not likely
 to happen - just want to know the reasoning behind it.

It mainly came down to not wanting to add new keywords. By using safe instead of safe, safe could still be used as a variable or function or whatnot. There was some discussion of which should have on them on which not (e.g. nothrow vs nothrow was debated), but the decision was fairly arbitrary. If anything though, had we not cared about breaking code or whether D looked similar to other languages, we probably would have made _all_ attributes start with (including stuff like public). It would have been wonderfully consistent that way, but it wasn't ultimately deemed a good idea. So, basically, was introduced to avoid adding more keywords. It certainly makes sense to extend it for using with user defined attributes, but that wasn't really the original intention. - Jonathan M Davis
Nov 07 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 November 2012 21:53, Walter Bright <newshound2 digitalmars.com> wrote:
 On 11/6/2012 1:41 PM, deadalnix wrote:
 Le 06/11/2012 22:02, Jonathan M Davis a =E9crit :
 On Tuesday, November 06, 2012 11:18:34 Walter Bright wrote:
 No hitting below the belt! Let the games begin!

Definitely (ArgumentList). It fits with what other languages do, and i=



 matches
 what we're already doing for attributes. I also think that's what prett=



 much
 everyone was figuring would be used for user-defined attributes. The on=



 major
 problem would be if  ArgumentList is allowed when there's only a single
 argument, then code could break when new built-in attributes are added.

Can you explain that code breakage ?

C++11 has had problems adding new keywords, as about every identifier somewhere has been used by someone's C++ source code, and they don't want=

 break existing code. So C++11 winds up with awful things like "decltype".

*cough* _Static_Assert *cough* --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Nov 07 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-12-07 11:11, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 11/07/2012 09:28 AM, Simen Kjaeraas wrote:
 On 2012-19-07 09:11, John Chapman <johnch_atms hotmail.com> wrote:

 Personally, I also like <ArgumentList>.

I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)>

This example does not show that they cause problems.

Not true. The compiler certainly can handle it, but a programmer could easily be confused. -- Simen
Nov 07 2012
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
     precedent with C#
     looks nice

 Cons:
     not so greppable
     parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
     looks like existing  attribute syntax
     no parsing problems

 Cons:
     not as nice looking
 ------

 No hitting below the belt! Let the games begin!

I prefer the (list) syntax because we already have attributes and that is what we are all familiar with. Regards
Nov 07 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 07, 2012 at 06:57:10AM +0100, Jakob Ovrum wrote:
 On Wednesday, 7 November 2012 at 05:53:35 UTC, Jakob Ovrum wrote:
I want to hear what people think about [] at declaration scope and
 [] at statement scope. Too complicated to remember?


Inconsistent. I don't like it.
 This is quite bad for a variety of reasons, I'll change my vote for
 purely having  [] then.

I still prefer (), for being easier to type on a variety of keyboards. T -- "Hi." "'Lo."
Nov 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 06 Nov 2012 22:53:36 +0100
Artur Skawina <art.08.09 gmail.com> wrote:
 
 " [ArgumentList]".
 

vote++ It has all the benefits of ' (...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org
Nov 07 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Wednesday, 7 November 2012 at 08:36:49 UTC, Jacob Carlborg 
wrote:
 On 2012-11-06 22:53, Walter Bright wrote:

 C++11 has had problems adding new keywords, as about every 
 identifier
 somewhere has been used by someone's C++ source code, and they 
 don't
 want to break existing code. So C++11 winds up with awful 
 things like
 "decltype".

Just create a new attribute, call it "builtin" or something similar, which takes attributes as arguments, i.e. builtin(shared) int a; builtin(property) int b; I'm not suggesting that we should change the existing shared and property, I just used them as an example.

I honestly don't get why we keep reinventing the concept of namespaces. I agree with Jonathan regarding the identifier look-up rules in D. "std.algorithm.find" really should be *the default* unless the user specifically aliases that to "find" whereas now we have the exact opposite. But even without this we still should use D's already existing namespace solution - *the module system*. We should take a lesson from other platforms such as Java and .NET where everything is neatly organized. Let's stop this global identifiers nightmare! On that note, here's some things we *should not do*: - put unrelated random stuff in object.d - add more redundant ways to define namespaces such as __identifier, builtin(identifier), attribute(identifier), identifier, etc, etc.. - add more keywords because they conflict with global identifiers. - have _huge_ single modules in Phobos that contain everything and ythe kitchen sink. I still hate with passion the "std.algorithm" "module". It's like opening a shop called "A Shop" or naming a newspaper "Newspaper". Proper organization is not inherently evil and we should not complicate the language design to compensate our current sloppiness.
Nov 07 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 07 Nov 2012 15:51:50 -0000, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 On Tue, 06 Nov 2012 22:53:36 +0100
 Artur Skawina <art.08.09 gmail.com> wrote:
 " [ArgumentList]".

vote++ It has all the benefits of ' (...)' (which are very compelling on their own), but also has the *ONE* benefit of '[...]': Much less getting lost in stupid parenthesis, as demonstrated here: http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

I hadn't replied to this thread earlier because I didn't have a strong opinion either way, but, this suggestion appears to be the best of both worlds. So.. vote++ R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 07 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 07 Nov 2012 09:19:41 +0100
schrieb "John Chapman" <johnch_atms hotmail.com>:

 [ ArgumentList ]

 Pros:
     precedent with C#

And Delphi.

That adds to the user base, but it is possible that in both cases Anders Hejlsberg was responsible for the design decision, making it more like a CDelphi# feature. :) -- Marco
Nov 07 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/06/2012 08:18 PM, Walter Bright wrote:
  ( ArgumentList )

 ...

I do not like that one as I already use the syntax.
Nov 07 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 9:00 AM, Timon Gehr wrote:
 On 11/06/2012 08:18 PM, Walter Bright wrote:
  ( ArgumentList )

 ...

I do not like that one as I already use the syntax.

That currently isn't accepted by the D compiler - what are you already using it for?
Nov 07 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/07/2012 09:20 PM, Walter Bright wrote:
 On 11/7/2012 9:00 AM, Timon Gehr wrote:
 On 11/06/2012 08:18 PM, Walter Bright wrote:
  ( ArgumentList )

 ...

I do not like that one as I already use the syntax.

That currently isn't accepted by the D compiler - what are you already using it for?

Text interpolation. enum d = "c"; mixin(X!"abc (d)ef"); // -> abccef I use it mostly for code generation. mixin(mixin(X!q{ if( (a)) (b); }));
Nov 07 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2012 1:16 PM, Timon Gehr wrote:
 Text interpolation.

 enum d = "c";

 mixin(X!"abc (d)ef"); // -> abccef

 I use it mostly for code generation.

 mixin(mixin(X!q{
      if( (a))  (b);
 }));

I see. How hard would it be to change it?
Nov 07 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/07/2012 11:42 PM, Walter Bright wrote:
 On 11/7/2012 1:16 PM, Timon Gehr wrote:
 Text interpolation.

 enum d = "c";

 mixin(X!"abc (d)ef"); // -> abccef

 I use it mostly for code generation.

 mixin(mixin(X!q{
      if( (a))  (b);
 }));

I see. How hard would it be to change it?

Not too hard, it can probably be automated. I do not have issues with fixing up my code after breaking changes. Even without this consideration, I still prefer [a,b,c]
Nov 07 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 22:16, Timon Gehr a écrit :
 On 11/07/2012 09:20 PM, Walter Bright wrote:
 On 11/7/2012 9:00 AM, Timon Gehr wrote:
 On 11/06/2012 08:18 PM, Walter Bright wrote:
  ( ArgumentList )

 ...

I do not like that one as I already use the syntax.

That currently isn't accepted by the D compiler - what are you already using it for?

Text interpolation. enum d = "c"; mixin(X!"abc (d)ef"); // -> abccef I use it mostly for code generation. mixin(mixin(X!q{ if( (a)) (b); }));

This can happen with any syntax addition. I usually use really bizantine stuff when I do that (like <{ a }>) so I'm sure to avoid the issue. Can't a convention be decided on that ?
Nov 07 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 22:16, Timon Gehr wrote:

 Text interpolation.

 enum d = "c";

 mixin(X!"abc (d)ef"); // -> abccef

 I use it mostly for code generation.

 mixin(mixin(X!q{
      if( (a))  (b);
 }));

This is what we need AST macros for. -- /Jacob Carlborg
Nov 08 2012
prev sibling next sibling parent "John Chapman" <johnch_atms hotmail.com> writes:
On Wednesday, 7 November 2012 at 11:29:16 UTC, Simen Kjaeraas 
wrote:
 On 2012-12-07 11:11, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 11/07/2012 09:28 AM, Simen Kjaeraas wrote:
 On 2012-19-07 09:11, John Chapman <johnch_atms hotmail.com> 
 wrote:

 Personally, I also like <ArgumentList>.

I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)>

This example does not show that they cause problems.

Not true. The compiler certainly can handle it, but a programmer could easily be confused.

I'm not putting it forward for consideration, but there is a precedent in Visual Basic - http://msdn.microsoft.com/en-US/library/h3z05kek%28v=vs.80%29.aspx
Nov 07 2012
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.11.2012 20:18, schrieb Walter Bright:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
      precedent with C#
      looks nice

 Cons:
      not so greppable
      parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
      looks like existing  attribute syntax
      no parsing problems

 Cons:
      not as nice looking
 ------

 No hitting below the belt! Let the games begin!

Already too late to the party. I join my voice to the () group. -- Paulo
Nov 07 2012
prev sibling next sibling parent "John Chapman" <johnch_atms hotmail.com> writes:
On Wednesday, 7 November 2012 at 16:55:23 UTC, Marco Leise wrote:
 Am Wed, 07 Nov 2012 09:19:41 +0100
 schrieb "John Chapman" <johnch_atms hotmail.com>:

 [ ArgumentList ]

 Pros:
     precedent with C#

And Delphi.

That adds to the user base, but it is possible that in both cases Anders Hejlsberg was responsible for the design decision, making it more like a CDelphi# feature. :)

Actually, C# got there first, Delphi not until 2010.
Nov 07 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
 (attribute) looks prettier to me, and with the other pros I 
think it's the clear winner. I always though C#'s [Attribute] 
syntax didn't make a lot of sense. I'm also for:  attr1  attr2 
int i; type syntax if that was being discussed previously 
(someone mentioned it). It would be very consistent with what's 
already there.

Congrats on Attributes, BTW! Great news :)
Nov 07 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 07 Nov 2012 18:17:20 -0000, Jacob Carlborg <doob me.com> wrote:

 On 2012-11-07 16:51, Nick Sabalausky wrote:

 vote++

 It has all the benefits of ' (...)' (which are very compelling on
 their own), but also has the *ONE* benefit of '[...]': Much less
 getting lost in stupid parenthesis, as demonstrated here:
 http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases

For comparison the same again using []: http://pastebin.com/vgjLSXMv I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!). Here it is with no highlighting: http://pastebin.com/08judqWj R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 07 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 07, 2012 at 06:28:54PM -0000, Regan Heath wrote:
 On Wed, 07 Nov 2012 18:17:20 -0000, Jacob Carlborg <doob me.com> wrote:
 
On 2012-11-07 16:51, Nick Sabalausky wrote:

vote++

It has all the benefits of ' (...)' (which are very compelling on
their own), but also has the *ONE* benefit of '[...]': Much less
getting lost in stupid parenthesis, as demonstrated here:
http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases

For comparison the same again using []: http://pastebin.com/vgjLSXMv I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!). Here it is with no highlighting: http://pastebin.com/08judqWj

Hmm. Having seen both () and [] in actual sample code, I have to say that () is visually less distracting and more pleasant to read (to me, anyway, YMMV). I don't like [] because it just stands out too much. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Nov 07 2012
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 7 November 2012 at 18:28:54 UTC, Regan Heath wrote:

 This is how that example would look like with my syntax:

 http://pastebin.com/8Ve5KS49

 I think it looks better in most cases

For comparison the same again using []: http://pastebin.com/vgjLSXMv I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!). Here it is with no highlighting: http://pastebin.com/08judqWj R

I like Jacobs proposal more. On many keyboards are [ and ] notoriously hard to type . Despite that: please make any form of brackets optional. I wouldn't consider any possibly breaking changes in the future for two reasons: First: New buildin UDA can go into modules and adhere to normal scoping rules. Second: When the time comes, we'll hopefully have enough reengineering tools that can fully qualify any conflicting uses of a name automatically.
Nov 07 2012
prev sibling next sibling parent "Jonas Drewsen" <nospam4321 hotmail.com> writes:
On Wednesday, 7 November 2012 at 09:23:44 UTC, Jonathan M Davis 
wrote:
 On Wednesday, November 07, 2012 10:13:47 Jonas Drewsen wrote:
 My vote goes to  (a,b,c) and  a  b  c.
 
 I never understood why some builtin storage class keywords 
 have  
 in front of them (e.g.  property,  safe,  disable) and some 
 don't
 (e.g. pure, nothrow).
 
 IMHO the cleanest design would be to have builtins as plain
 keywords (ie. no   in front). And then  xxx is reserved for 
 UDA.
 
 I understand that this would be a breaking change and not 
 likely
 to happen - just want to know the reasoning behind it.

It mainly came down to not wanting to add new keywords. By using safe instead of safe, safe could still be used as a variable or function or whatnot. There was some discussion of which should have on them on which not (e.g. nothrow vs nothrow was debated), but the decision was fairly arbitrary. If anything though, had we not cared about breaking code or whether D looked similar to other languages, we probably would have made _all_ attributes start with (including stuff like public). It would have been wonderfully consistent that way, but it wasn't ultimately deemed a good idea. So, basically, was introduced to avoid adding more keywords. It certainly makes sense to extend it for using with user defined attributes, but that wasn't really the original intention. - Jonathan M Davis

I we were to allow for foobar style UDA then "safe" would have to be a reserved keyword somehow. Otherwise I do not know what this would mean: struct safe { } safe void foobar() { } /Jonas
Nov 07 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-11-07, 18:03, John Chapman wrote:

 On Wednesday, 7 November 2012 at 11:29:16 UTC, Simen Kjaeraas wrote:
 On 2012-12-07 11:11, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 11/07/2012 09:28 AM, Simen Kjaeraas wrote:
 On 2012-19-07 09:11, John Chapman <johnch_atms hotmail.com> wrote:

 Personally, I also like <ArgumentList>.

I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)>

This example does not show that they cause problems.

Not true. The compiler certainly can handle it, but a programmer could easily be confused.

I'm not putting it forward for consideration, but there is a precedent in Visual Basic - http://msdn.microsoft.com/en-US/library/h3z05kek%28v=vs.80%29.aspx

I think that's the first time I've heard someone suggest something be borrowed from VB. :p -- Simen
Nov 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 07 Nov 2012 19:17:20 +0100
Jacob Carlborg <doob me.com> wrote:

 On 2012-11-07 16:51, Nick Sabalausky wrote:
 
 vote++

 It has all the benefits of ' (...)' (which are very compelling on
 their own), but also has the *ONE* benefit of '[...]': Much less
 getting lost in stupid parenthesis, as demonstrated here:
 http://forum.dlang.org/thread/k7afq6$2832$1 digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

This is how that example would look like with my syntax: http://pastebin.com/8Ve5KS49 I think it looks better in most cases

Well, I'm in favor of the attr shortcut regardless of [] vs ().
Nov 07 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/11/2012 20:18, Walter Bright a écrit :
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
 precedent with C#
 looks nice

 Cons:
 not so greppable
 parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
 looks like existing  attribute syntax
 no parsing problems

 Cons:
 not as nice looking
 ------

 No hitting below the belt! Let the games begin!

About () vs [] the key point to me is that this is consistent with tuple syntax (which don't exists yet \o/). The important point to me is that a is allowed.
Nov 07 2012
prev sibling next sibling parent reply "nazriel" <spam dzfl.pl> writes:
On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
     precedent with C#
     looks nice

 Cons:
     not so greppable
     parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
     looks like existing  attribute syntax
     no parsing problems

 Cons:
     not as nice looking
 ------

 No hitting below the belt! Let the games begin!

() with required (). So we will still have place for new language attributes like rox etc ;)
Nov 07 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 08/11/2012 00:14, nazriel a écrit :
 On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
 For User Defined Attributes.

 In the north corner we have the current champeeeeon:

 -------
 [ ArgumentList ]

 Pros:
 precedent with C#
 looks nice

 Cons:
 not so greppable
 parsing ambiguity with [array literal].func();

 ------
 In the south corner, there's the chaaaaallenger:

  ( ArgumentList )

 Pros:
 looks like existing  attribute syntax
 no parsing problems

 Cons:
 not as nice looking
 ------

 No hitting below the belt! Let the games begin!

() with required (). So we will still have place for new language attributes like rox etc ;)

Language attribute must die :D
Nov 07 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu 
wrote:
 I think it's solvable. The basic approach would be to plop 
 types "safe", "nothrow" etc. in object.di and then let them 
 just behave like all other arguments.

"nothrow" isn't actually an attribute. So much for the value of consistency… :o) David
Nov 07 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/8/12, David Nadlinger <see klickverbot.at> wrote:
 On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu
 wrote:
 "nothrow" isn't actually an  attribute. So much for the value of
 consistency=85 :o)

Another classic inconsistency: disable and deprecated Not only that but I keep writing the former as disabled and get CT errors.
Nov 07 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 07 Nov 2012 16:19:56 +0100
schrieb Jacob Carlborg <doob me.com>:

 On 2012-11-07 14:40, deadalnix wrote:
 
 I think D has already too many feature, and that many of them can be
 implemented as attribute + AST processing.

 D should work toward getting this AST stuff and stop adding new keywords
 all the time.

I completely agree.

Which features are that? It would likely require a major rewrite of many routines. Who would want to go through all that and the following wave of bugs - some of which may have already occurred in the past. foreach and scope(...) lowerings are essentially AST operations. Are there other D features you would implement as AST processing, maybe a link to an earlier post ? How close is Rust currently to offering flexible AST manipulation for lowerings/attributes/macros, does anyone know ? -- Marco
Nov 07 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 07 Nov 2012 14:40:33 -0800
Walter Bright <newshound2 digitalmars.com> wrote:
 
 Of course we all take it for granted that Basic sux and does
 everything wrong,

Which Basic? ;) (<-- Just as one example)
Nov 07 2012
prev sibling next sibling parent "Jonas Drewsen" <nospam4321 hotmail.com> writes:
On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu 
wrote:
 On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would 
 have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

The original argument that the in front of safe is a way to prevent introducing new keywords is all gone then since "safe" becomes a normal symbol which is reserved in the library and in the compiler to let it do its magic. Then safe could just as well be a normal builtin storage class called "safe". * Plopping types "safe","nothrow" etc. into object.di would be a breaking change. * Making safe, nothrow into keywords called "safe", "nothrow" would be breaking change. The latter would be the cleanest cut and not have the semantic/parse stage problems that Walter mentioned. Another option would to enforce parenthesis (safe) for UDA which would make it less nice for the eyes to look at. /Jonas
Nov 08 2012
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 8 November 2012 at 11:01:13 UTC, Jonas Drewsen wrote:
 On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei 
 Alexandrescu wrote:
 On 11/7/12 10:24 PM, Walter Bright wrote:
 On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
 I we were to allow for  foobar style UDA then "safe" would 
 have to be
 a reserved
 keyword somehow. Otherwise I do not know what this would 
 mean:

 struct safe { }
  safe void foobar() { }

Yes, I agree this is a significant problem.

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

The original argument that the in front of safe is a way to prevent introducing new keywords is all gone then since "safe" becomes a normal symbol which is reserved in the library and in the compiler to let it do its magic. Then safe could just as well be a normal builtin storage class called "safe". * Plopping types "safe","nothrow" etc. into object.di would be a breaking change. * Making safe, nothrow into keywords called "safe", "nothrow" would be breaking change. The latter would be the cleanest cut and not have the semantic/parse stage problems that Walter mentioned. Another option would to enforce parenthesis (safe) for UDA which would make it less nice for the eyes to look at. /Jonas

Not safe but safe should become a keyword.
Nov 08 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 08 Nov 2012 21:53:11 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 11/7/2012 5:40 PM, deadalnix =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 I think D has already too many feature, and that many of them can be
 implemented as attribute + AST processing.

+1 =20

Doesn't that still amount to the same amount of features though? At least from the user's standpoint anyway. Plus, I would imagine that library-implemented features would be slower to compile (simply because it's just that much more to be compiled). Not that I'm necessarily saying "Always stuff everything into the language forever!" I just don't see it as quite so clear-cut.
Nov 08 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 8 Nov 2012 14:27:14 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 [...]Plus, I would imagine
 that library-implemented features would be slower to compile (simply
 because it's just that much more to be compiled).

Also, these particular sorts of things (compile time processing of things that are in-library) essentially amount to executing interpreted code to compile. Sure, that's very powerful, and very well worth having, but should it really be done for very common features? For common features, I'd imagine native non-"interpreted" support would help compilation speed, which is one of D's major goals and benefits. Suddenly interpreting large parts of the language might work against that.
 
 Not that I'm necessarily saying "Always stuff everything into the
 language forever!" I just don't see it as quite so clear-cut.
 

Nov 08 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-11-09, 15:26, deadalnix wrote:

 Le 08/11/2012 01:14, Andrej Mitrovic a =C3=A9crit :
 On 11/8/12, David Nadlinger<see klickverbot.at>  wrote:
 On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu
 wrote:
 "nothrow" isn't actually an  attribute. So much for the value of
 consistency=E2=80=A6 :o)

Another classic inconsistency: disable and deprecated Not only that but I keep writing the former as disabled and get CT =


 errors.

Good new for you, with the given proposal, you'll be able to do alias deprecate deprecated;

Or even: alias deprecated =3D deprecate; -- = Simen
Nov 09 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 09 Nov 2012 15:28:40 +0100
schrieb deadalnix <deadalnix gmail.com>:

 nothrow is already a keyword (which is really inconsistent). I'm not 
 sure what it does buy us, and both safe and nothrow are good candidates 
 for lib implementation rather than compiler support.

That requires that the compiler exposes all sorts of statistical data for every statement. E.g. to check if nothrow is violated you have to find statements that throw something and then check if there is a catch block around that, that catches it. If a statement is a function call, you would ask the compiler if that function throws. (In particular if it is a templated function with deduced 'nothrow' and ' safe'). And there you are at the point that you just duplicated the compiler code in the library. -- Marco
Nov 10 2012