https://issues.dlang.org/show_bug.cgi?id=13388

Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com

--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
Despite being "more syntax" I'm very much in favor of this change. It makes it that much easier to remember which attributes need or don't need the at sign. I frequently make the mistake of miss-tagging due to the current situation.

--

https://issues.dlang.org/show_bug.cgi?id=13388

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #2 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
Created attachment 1392
  --> https://issues.dlang.org/attachment.cgi?id=1392&action=edit
testcase: must compile

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #3 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
Created attachment 1393
  --> https://issues.dlang.org/attachment.cgi?id=1393&action=edit
testcase: must fail with "'mustf.foo' is not nothrow"

--

https://issues.dlang.org/show_bug.cgi?id=13388

Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com

--- Comment #4 from Jonathan M Davis <jmdavisProg@gmx.com> ---
I'm very much against this because then it's possible to have both nothrow and @nothrow in code (and the same for the others), and that's just going to create confusion. Right now at least, it's clear when you get it wrong, because you get a compilation error, but if we allowed this, then many users won't know the difference between the two, and confusion and questions will ensue. I really think that they should be one way or the other and not both.

In addition, it's not like this makes everything consistent, because attributes like static or const wouldn't ever have @ on them. If this change were forced, all it would do is move some of the attributes from keywords to the @ side - it wouldn't actually make them all consistent- and making it so that you _can_ mark some of them with @ but don't have to is just going to increase confusion and inconsistencies between programs. This isn't just not worth it IMHO; it's detrimental.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #5 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
i can't see why we can't turn const to '@const' too. this will remove long-standing 'const confusion': '@const' can be only function attribute.

i didn't do it in this patch 'cause i believe that it's two very different changes, and '@const' patch has no sense without this patch.

about 'static': this is not an 'attribute' like 'nothrow', 'cause we can't write:

  void bar () static {}

(why, btw?)

i agree that enforcing '@' syntax is The Right Thing, but this will break alot of code. allowing '@' is a little step towards consistency. yes, it makes some mess, but it will allow to deprecate non-UDA attributes in the future.

i believe that turning D in C++ with "ah, we know about this inconsistent crap, but it's our legacy and we have to live with it" will harm D in the long run. language that trades developement for stability will become C++.

current attribute syntax is a mess. let's clean it up: first by allowing two syntaxes (ok, it's confusing, but leaves some time to fix the old code) and then by deprecating non-UDA syntax. if we will not do the first, we will never do the second.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> ---
(In reply to Ketmar Dark from comment #5)

> about 'static': this is not an 'attribute' like 'nothrow', 'cause we can't write:
> 
>   void bar () static {}
> 
> (why, btw?)

public, private, etc. are in the same boat:

https://issues.dlang.org/show_bug.cgi?id=12930

The attributes are treated consistently in general, which sucks, and I think that the placement issues can and should be fixed, but I don't think changing any of the attributes to @ is even vaguely worth it, especially considering the resulting code breakage (not to mention, it's very ugly for them all to start with @ IMHO). Just think of the @ as part of the name, and the inconsistency goes away anyway, since then you just have some attributes which happen to start with the same character, just like happens with attributes like private and public. With that line of thought, complaining about some attributes starting with @ and some not would be like complaining that some attributes started with p and some didnt'.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #7 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
> Just think of the @ as part of the name, and the inconsistency goes away anyway

no, it's not. it's ok to remember *words*, but it's not ok to remember which word should be prepended with 'sigil'.

it can be ok for attributes with meaningless names. there is really no much difference between '@riogjheo' and 'riogjheo' — they both sux and hard to remember. but making some *words* special… why '@safe' needs '@' and 'pure' don't? what is so special about the word 'pure' (or 'safe')? why should i remember this nonsence?

ok, we can go another way: strip out all '@' from compiler-defined attributes. and we can do this without introducing new keywords — just forbid prefix attributes. so

  void foo () system;

will not require "system" to be a keyword, and we can declare and use variables with the name 'system' in other code.

this patch is little more intrusive, but i can try to write it. do you think that it will be better alternative to this one?

--

https://issues.dlang.org/show_bug.cgi?id=13388

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #8 from bearophile_hugs@eml.cc ---
I don't think this is a good idea because:
- It goes against the rule that there should be only one obvious way to do
something;
- It's a change that introduces nothing new that is useful in D;
- It will increase the frequency of the '@' symbol in D source code, that I
find noisy to read and not easy to write with my keyboard;
- This topic was discussed a lot (tens or hundreds of posts) in past when
@trusted, @safe and @system were introduced. I don't think there are new points
to be added now.

So I vote for wontfix.

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #9 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
ok, i did it another way: https://issues.dlang.org/show_bug.cgi?id=13397

this time we can omit '@' before postfix attributes. ;-)

--

https://issues.dlang.org/show_bug.cgi?id=13388

--- Comment #10 from Trey Brisbane <tbrisbane@gmail.com> ---
I think this should be looked at in terms of conceptual differences between the attributes using keyword notation, vs. those using @-prefix notation, as well as compliance to C compatibility.

For instance, why are static, const, immutable, final, shared, __gshared, and deprecated, keywords, while @property, @safe, @trusted, @system, @disable, and @nogc, are UDAs? What is the underlying conceptual difference here that necessitates the separation?

I'm not sure anyone really knows, and that's why we have this problem in the first place. I think we can safely say that const, static, public, protected, private, etc are keywords to conform to C/C++ code-style, but what about the rest?

The following is what I'd do given the option, and what would be (IMO) a great system to adopt in the language, but this is just my opinion and I'm sure others would disagree:

Keywords: extern, align, package, private, protected, public, export, pragma,
static, extern, abstract, final, synchronized, auto (shouldn't this be a
type?), scope, const (shouldn't this be part of the type?), immutable
(shouldn't this be part of the type?), inout, shared, __gshared, property, and
ref (shouldn't this be part of the type?).

UDAs: deprecated, override, nothrow, pure, safe, trusted, system, disable, nogc.

In terms of a general solution, I see it as though we have 4 options:
1) Resolve the inconsistency through community engagement and voting (ala.
democracy)
2) Resolve the inconsistency by going all or nothing in either direction (i.e.
all UDAs or all keywords)
3) Define the requirements/rational for attributes to exist in one category vs.
the other, so that developers have a conceptual grounding when trying to
rationalize the difference
4) Allow either notation for either some or even all of the attributes,
documenting the idiomatic way, and let the developers ultimately decide

Given that there seems to be a detrimentally-large resistance to breaking changes in the language (which is a little concerning in itself), I see option 4 as the only reasonable way forward.

@Jonathan:
I understand your angle with regard to user confusion, but given the
alternatives are either never ever fixing this, or breaking changes, are you
sure you'd rather go down the route of never fixing this? User confusion can be
addressed by making appropriate documentation for this change. I.e. State in
the documentation that the idiomatic way is to use @-style notation, but that
not including it also works for legacy reasons. Done. Old code doesn't break,
and new users will have to read the documentation anyway.

@bearophile:
On only doing things one true way, see here why this argument makese no sense:
http://dlang.org/pragma.html#Pragma
On not adding anything useful to D, I disagree. Fixing this issue in some way
or another adds consistency and elegance to the language. When I show people D
code, almost invariably people say things along the lines of "Why does property
require the @-symbol, where as nothrow doesn't?", followed immediately by "Eww,
well that just looks ugly.". In my experience, it's a build-up of little dirty
bits here and there that wards off adoption of a new language with most people,
because it means they're forced to *look at* the problems with the language,
and often can't get past that even when shown the best features of said
language. D should strive to fix things like this, because if the syntax is
absolutely clean and elegant, then at least people won't have to *look at*
problems in the language.

--