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.
>> 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.
>
> - Jonathan M Davis

Language attribute can be added in object.d and regular lookup rule apply.

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.

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.

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

@(Attr...) and @attr1 @attr2


Because I secretly dream about stuff like:

	alias @(nothrow,safe,memoizable) @memosafe;
	@memosafe int foo(){...}

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.

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

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.

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

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