November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to kraybourne | On 11/7/12 2:27 AM, kraybourne wrote:
>
> @(Attr...) and @attr1 @attr2
>
>
> Because I secretly dream about stuff like:
>
> alias @(nothrow,safe,memoizable) @memosafe;
Sure you mean
alias @memosafe = @(nothrow,safe,memoizable);
Andrei
|
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
> No hitting below the belt! Let the games begin!
I think that [] is sufficiently distinct from built-in attributes, unlike @(), but sadly, there's no nice way to parse it at statement scope. There are in fact a couple of ambiguous cases in the parser already; let's not introduce any more, lest we lose the ability to call D easy to parse.
@(foo) looks too similar to built-in attributes. And let's face it; these annotations are actually quite different (I too prefer the more accurate name, 'annotations') from built-in attributes, the former cannot replace the latter any time soon.
I want to hear what people think about [] at declaration scope and @[] at statement scope. Too complicated to remember?
|
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | On Wednesday, 7 November 2012 at 05:53:35 UTC, Jakob Ovrum wrote:
> I want to hear what people think about [] at declaration scope and @[] at statement scope. Too complicated to remember?
This is quite bad for a variety of reasons, I'll change my vote for purely having @[] then.
|
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | > [ ArgumentList ] > > Pros: > precedent with C# And Delphi. > @( ArgumentList ) > > Pros: > looks like existing @attribute syntax > no parsing problems > > Cons: > not as nice looking @ArgumentList makes me think I'm on Twitter. #joke Personally, I also like <ArgumentList>. Prior to @property and family being introduced, I'd have gone with [ArgumentList]. But since @ is the prefix for attributes in D, let's stick with it for UDAs. And as to any clashes between UDAs and possible future built-in ones, I'd say the language has first dibs on names and it's up to people writing UDAs to avoid using names that sound like language constructs. |
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Chapman | On 2012-19-07 09:11, John Chapman <johnch_atms@hotmail.com> wrote: > Personally, I also like <ArgumentList>. I am glad to say this will not happen. <> as delimiters cause problems because they're used elsewhere as non-matching: <MyAttribute(foo > bar)> -- Simen |
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 11/06/2012 10:18 AM, Walter Bright wrote: > For User Defined Attributes. > > In the north corner we have the current champeeeeon: > > ------- > [ ArgumentList ] > > Pros: > precedent with C# > looks nice > > Cons: > not so greppable > parsing ambiguity with [array literal].func(); > > ------ > In the south corner, there's the chaaaaallenger: > > @( ArgumentList ) > > Pros: > looks like existing @attribute syntax > no parsing problems > > Cons: > not as nice looking > ------ > > No hitting below the belt! Let the games begin! [], because @ should be reserved for future language keywords. Whenever people post suggested language features that require some marking, they introduce a new @attribute, because introducing a plain keyword breaks code. If you have @UDAs, this further limits language expansion. Example: let's say you want to introduce a "nogc" mark: 1. Not a nogc keyword, that could break "bool nogc;" 2. If you have @, @nogc could break an "enum nogc;" attribute. 3. Now you're stuck with __nogc or #nogc or something uglier. There is a familiar-to-other-langauges advantage to @, but there is a better-than-other-languages advantage to []. My thoughts, NMS |
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2012-11-06 22:53, Walter Bright wrote: > 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". Just create a new attribute, call it "builtin" or something similar, which takes attributes as arguments, i.e. @builtin(shared) int a; @builtin(property) int b; I'm not suggesting that we should change the existing @shared and @property, I just used them as an example. -- /Jacob Carlborg |
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2012-11-06 22:38, Walter Bright wrote: > On 11/6/2012 1:07 PM, Tavi Cacina wrote: >> On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote: >>> No hitting below the belt! Let the games begin! >> >> @ > > > 2 penalty points for that one! The @( ArgumentList ) syntax still wins :) -- /Jacob Carlborg |
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Caligo | On 2012-11-06 22:26, Caligo wrote: > If those are our only choices, then I vote for @( ArgumentList ). > > Otherwise, I think these look better: > > [: ArgumentList :] > > or > > |: ArgumentList :| > These are just horrible. -- /Jacob Carlborg |
November 07, 2012 Re: [ ArgumentList ] vs. @( ArgumentList ) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 11/7/12 03:48 , Andrei Alexandrescu wrote:
> Sure you mean
>
> alias @memosafe = @(nothrow,safe,memoizable);
>
>
> Andrei
Mind = blown :)
|
Copyright © 1999-2021 by the D Language Foundation