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.
