On 11/6/2012 1:26 PM, Caligo wrote:
> On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright
> <newshound2@digitalmars.com> wrote:
>>
>> No hitting below the belt! Let the games begin!
>
> If those are our only choices, then I vote for @( ArgumentList ).
>
> Otherwise, I think these look better:
>
> [: ArgumentList :]
>
> or
>
> |: ArgumentList :|
>

:-)

@

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 ?

On Tue, Nov 06, 2012 at 03:26:53PM -0600, Caligo wrote:
> On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright <newshound2@digitalmars.com> wrote:
> >
> > No hitting below the belt! Let the games begin!
> 
> If those are our only choices, then I vote for @( ArgumentList ).
> 
> Otherwise, I think these look better:
> 
> [: ArgumentList :]
> 
> or
> 
> |: ArgumentList :|

They look like smileys to me. To me, they look worse than @Arg.


T

-- 
Once bitten, twice cry...

On 11/06/2012 01:39 PM, Walter Bright wrote:
> On 11/6/2012 1:26 PM, Caligo wrote:
>> On Tue, Nov 6, 2012 at 1:18 PM, Walter Bright
>> <newshound2@digitalmars.com> wrote:
>>>
>>> No hitting below the belt! Let the games begin!
>>
>> If those are our only choices, then I vote for @( ArgumentList ).
>>
>> Otherwise, I think these look better:
>>
>> [: ArgumentList :]
>>
>> or
>>
>> |: ArgumentList :|
>>
>
> :-)
>

More explicitly:

  (-: ArgumentList :-)

Ali

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

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.

As to the syntax - it doesn't matter, as long as it isn't "[ArgumentList]" as that one is ambiguous (from a programmer POV, even if the compiler could deal with it - which i'm not convinced is the case here, considering all contexts where attributes have to be allowed and the inevitable evolution of this feature).

"@[ArgumentList]".

artur

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.

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

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