On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler
wrote:
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.
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?
The consistency issue is precisely that there should not be
more than one way to write an attribute. Note that that's
precisely where most of the opposition to this thread's
original proposal came from. Uniformity means never having to
explain to anybody why there is more than one way to do
something. Both this thread's proposal and your proposal
*introduce* inconsistency in this way.
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.
This will annoy people even more than they are already annoyed
by the `@`-on-some-attributes-and-not-others inconsistency. The
latter type (type 2 in my first thread) already exists in the
language, but it shoudln't be replaced by another type. This
argument was already made by Jonathan Davis.
Yes you're right it adds more inconsistency (sorry what I said
was wrong). However, no matter what solution you choose you have
to choose one of two evils. Either add inconsistency or break
code. There's no way around it. If you ADD another way to write
the attributes that looks better, you've created more
"inconsistency". If you REPLACE the existing way to write
attributes, you've now broken code.
I proposed that we ADD another way of writing attributes,
however, my proposal doesn't require that we ADD another way,
instead, we can REPLACE the current way of writing attributes by
normalizing where they appear. However, like I said, you have to
choose one or the other, broken code or inconsistency.
The nice part about ADDING another way of writing attributes is
that the hope is that the inconsistency will be solved in the
future. Changing the way to write attributes will introduce more
inconsistency at first. However, the hope is that if the new way
is "better" or looks "nicer", then developers will hopefully
consistently choose the new way. Then, if there's no reason to
keep the old way, it can be deprecated and the consistency issue
is solved.
So again, I was suggesting one way of implementing my proposal
which was to add an inconsistency, but you could implement it
another way but you would have to break code. Do you have a
solution that doesn't do either? I think if you try to find one,
you'll see that I'm right in saying you're going to have to
choose one or the other.
