[ ArgumentList ] vs. @( ArgumentList )

[deadalnix]

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.