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

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

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

*cough* _Static_Assert *cough*

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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.

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

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

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

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

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.

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