[ ArgumentList ] vs. @( ArgumentList )

[Artur Skawina]

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