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?

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.

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

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

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

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