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

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

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

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

On 11/7/12 03:48 , Andrei Alexandrescu wrote:
> Sure you mean
>
> alias @memosafe = @(nothrow,safe,memoizable);
>
>
> Andrei

Mind = blown :)