View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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 :|
>

:-)
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
@
November 06, 2012
Re: [ ArgumentList ] vs. @( 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 ?
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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...
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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".
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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.
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home