[ ArgumentList ] vs. @( ArgumentList )

[Jonathan M Davis]

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