Am 06.11.2012 20:52, schrieb Manu:
> I'd like to re-enforce the consideration that @attribute() makes it
> looks like they affect the code generation somehow... they're really
> just annotations.
>
>
> On 6 November 2012 21:47, Jacob Carlborg <doob@me.com
> <mailto:doob@me.com>> wrote:
>
>     On 2012-11-06 20:18, 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!
>
>
>     I vote for @( ArgumentList ). If this is syntax chosen I also hope
>     @attribute will be legal as well.
>
>     --
>     /Jacob Carlborg
>
>


Speaking from C# point of view, the same argument can be used, because in .NET [] attributes might change the way the code gets generated.

Some of them like are even reckognized by the JIT/NGEN.

--
Paulo

@(attribute) looks prettier to me, and with the other pros I think it's the clear winner. I always though C#'s [Attribute] syntax didn't make a lot of sense. I'm also for: @attr1 @attr2 int i; type syntax if that was being discussed previously (someone mentioned it). It would be very consistent with what's already there.

Congrats on Attributes, BTW! Great news :)

"Regan Heath" <regan@netmail.co.nz> wrote
> On Wed, 07 Nov 2012 15:51:50 -0000, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
>
>> On Tue, 06 Nov 2012 22:53:36 +0100
>> Artur Skawina <art.08.09@gmail.com> wrote:
>>>
>>> "@[ArgumentList]".
>>>
>>
>> vote++
>>
>> It has all the benefits of '@(...)' (which are very compelling on
>> their own), but also has the *ONE* benefit of '[...]': Much less
>> getting lost in stupid parenthesis, as demonstrated here:
>> http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org
>
> I hadn't replied to this thread earlier because I didn't have a strong opinion either way, but, this suggestion appears to be the best of both worlds. So..
>
> vote++

+1

On 2012-11-07 16:51, Nick Sabalausky wrote:

> vote++
>
> It has all the benefits of '@(...)' (which are very compelling on
> their own), but also has the *ONE* benefit of '[...]': Much less
> getting lost in stupid parenthesis, as demonstrated here:
> http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org

This is how that example would look like with my syntax:

http://pastebin.com/8Ve5KS49

I think it looks better in most cases

-- 
/Jacob Carlborg

On Wed, 07 Nov 2012 18:17:20 -0000, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-07 16:51, Nick Sabalausky wrote:
>
>> vote++
>>
>> It has all the benefits of '@(...)' (which are very compelling on
>> their own), but also has the *ONE* benefit of '[...]': Much less
>> getting lost in stupid parenthesis, as demonstrated here:
>> http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org
>
> This is how that example would look like with my syntax:
>
> http://pastebin.com/8Ve5KS49
>
> I think it looks better in most cases

For comparison the same again using @[]:
http://pastebin.com/vgjLSXMv

I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!).

Here it is with no highlighting:
http://pastebin.com/08judqWj

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, Nov 07, 2012 at 06:28:54PM -0000, Regan Heath wrote:
> On Wed, 07 Nov 2012 18:17:20 -0000, Jacob Carlborg <doob@me.com> wrote:
> 
> >On 2012-11-07 16:51, Nick Sabalausky wrote:
> >
> >>vote++
> >>
> >>It has all the benefits of '@(...)' (which are very compelling on
> >>their own), but also has the *ONE* benefit of '[...]': Much less
> >>getting lost in stupid parenthesis, as demonstrated here:
> >>http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com?page=14#post-puseurlcwbgvigwkdowu:40forum.dlang.org
> >
> >This is how that example would look like with my syntax:
> >
> >http://pastebin.com/8Ve5KS49
> >
> >I think it looks better in most cases
> 
> For comparison the same again using @[]: http://pastebin.com/vgjLSXMv
> 
> I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!).
> 
> Here it is with no highlighting: http://pastebin.com/08judqWj
[...]

Hmm. Having seen both @() and @[] in actual sample code, I have to say
that @() is visually less distracting and more pleasant to read (to me,
anyway, YMMV). I don't like @[] because it just stands out too much.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On Wednesday, 7 November 2012 at 18:28:54 UTC, Regan Heath wrote:

>> This is how that example would look like with my syntax:
>>
>> http://pastebin.com/8Ve5KS49
>>
>> I think it looks better in most cases
>
> For comparison the same again using @[]:
> http://pastebin.com/vgjLSXMv
>
> I actually think the pastebin syntax highlighting makes both of them look worse (why the horrid green!).
>
> Here it is with no highlighting:
> http://pastebin.com/08judqWj
>
> R

I like Jacobs proposal more. On many keyboards are [ and ] notoriously hard to type . Despite that: please make any form of brackets optional. I wouldn't consider any possibly breaking changes in the future for two reasons:

First: New buildin UDA can go into modules and adhere to normal scoping rules.
Second: When the time comes, we'll hopefully have enough reengineering tools that can fully qualify any conflicting uses of a name automatically.

Le 07/11/2012 19:44, Tobias Pankrath a écrit :
> Second: When the time comes, we'll hopefully have enough reengineering
> tools that can fully qualify any conflicting uses of a name automatically.
>

As long as SURPRISE feature are added to master, that is not gonna happen.

On Wednesday, 7 November 2012 at 09:23:44 UTC, Jonathan M Davis wrote:
> On Wednesday, November 07, 2012 10:13:47 Jonas Drewsen wrote:
>> My vote goes to @(a,b,c) and @a @b @c.
>> 
>> I never understood why some builtin storage class keywords have @
>> in front of them (e.g. @property, @safe, @disable) and some don't
>> (e.g. pure, nothrow).
>> 
>> IMHO the cleanest design would be to have builtins as plain
>> keywords (ie. no @ in front). And then @xxx is reserved for UDA.
>> 
>> I understand that this would be a breaking change and not likely
>> to happen - just want to know the reasoning behind it.
>
> It mainly came down to not wanting to add new keywords. By using @safe instead
> of safe, safe could still be used as a variable or function or whatnot. There
> was some discussion of which should have @ on them on which not (e.g. nothrow
> vs @nothrow was debated), but the decision was fairly arbitrary. If anything
> though, had we not cared about breaking code or whether D looked similar to
> other languages, we probably would have made _all_ attributes start with @
> (including stuff like @public). It would have been wonderfully consistent that
> way, but it wasn't ultimately deemed a good idea.
>
> So, basically, @ was introduced to avoid adding more keywords. It certainly
> makes sense to extend it for using with user defined attributes, but that
> wasn't really the original intention.
>
> - Jonathan M Davis

I we were to allow for @foobar style UDA then "safe" would have to be a reserved keyword somehow. Otherwise I do not know what this would mean:

struct safe { }
@safe void foobar() { }

/Jonas

On 11/7/2012 9:00 AM, Timon Gehr wrote:
> On 11/06/2012 08:18 PM, Walter Bright wrote:
>>
>> @( ArgumentList )
>>
>> ...
>
> I do not like that one as I already use the syntax.

That currently isn't accepted by the D compiler - what are you already using it for?