On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler
wrote:
Haha, ok, sorry for being too abstract.
I think a safe way to implement my proposal would be to do
what c++ did and only allow non-keyword function attributes to
omit the '@' symbol if they appear after the function
signature:
Here's what would change
-----------------------------------------------------------------
void myfunc() nogc; // VALID (Only if this proposal is
accepted)
void myfunc() safe; // VALID (Only if this proposal is
accepted)
Here's what WOULD NOT change
-----------------------------------------------------------------
nogc myfunc(); // STILL INVALID: invalid unless it can be
verified
// that this wouldn't result in
ambiguity
// in the grammar
void myfunc() @nogc; // STILL VALID (no change)
@nogc myfunc(); // STILL VALID (no change)
If the initial proposal is accepted by people, then we can
talk about the other examples, but let's focus on the proposal
before focusing on sub-proposals.
Alright, good. However... I'm still against it. Firstly, in my
first comment in the current thread,
http://forum.dlang.org/post/[email protected]
...I made a list of considerations, among which:
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.
This alone puts me at next to zero for your proposal in terms
of benefit. It will strike people as a strange and unnecessary
exception to the way to mark their attributes, for the sake of
a slight beautification of only those cases where the
attributes come after the signature. Consider me an
old-fashioned "a keyword is a keyword is a keyword" kind of
guy. Yes, there are outliers (C++, D, exit, success, etc.), but
I don't see why that list should be expanded, as it is nicely
contained, IMO.
I agree that the proposal doesn't solve the consistency issue,
but the proposal doesn't make things more inconsistent then they
already are. It adds another way to write these attributes, but
it adds a way that makes more sense in my opinion. This is a
step in the right direction in solving the problem. The next
step would be to solve the consistency issue, but again, that's
another debate. To conclude, which code would you rather write?
void myfunc() pure @safe nothrow @nogc;
void myfunc() pure safe nothrow nogc;
This will inevitably result in someone writing this:
pure safe nothrow nogc void myfunc();
which would still be invalid in this proposal, and I think this
is still a problem but not a huge one since this is easily caught
by the compiler.
