On Thursday, 15 December 2016 at 00:08:12 UTC, 01010100b wrote:
On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M
Davis wrote:
Actually slapping @ on all keywords would remove the
inconsistency altogether, even if that isn't necessarily what I
favour. Keywords which are also function attributes would seem
a better set to allow @ on. While it is true that this reduced
set of keywords would be "shuffling an inconsistency around"
that still leaves open whether this inconsistency:
final pure @nogc func()
final class G{}
is preferable over this one:
@final @pure @nogc func()
final class G{}
How on earth is that preferable? In the first case, every single
attribute is always the same. In the second, sometimes they have
@, sometimes they don't, and programmers would have to know when
which was used. And as soon as you slap @ on attributes that
exist in other languages, you've made D harder to learn, and
you've made it harder to port code from other languages to D.
But even worse, you're then introducing yet another way to do
exactly the same thing in D without it adding any new
functionality. There will be questions over what the
difference between @pure and pure is. There will be questions
about why you can use both @pure and pure, but you're forced
to use @safe instead of safe. There will be yet more arguments
over coding style and whether it's better to use @pure or pure.
There will always be arguments over coding style, but this
isn't one of them, it's about language design.
If you optionally allow @ on attributes, it definitely becomes a
question of coding style - e.g. some code will use pure and some
will use @pure. And you get all of the arguments over whether a
codebase should use @ or not and whether it's acceptable to mix
them. The only way that this does not become a coding style
question is if we change the keywords rather than having two
versions of them. Optional syntax pretty much always leads to
arguments about coding style.
Except that it isn't easier to learn, because you still have
stuff like pure and nothrow in addition to their @
counterparts, meaning that there's _more_ to learn
Why would you need to learn pure or nothrow in addition to
their @ counterparts?
It's terrible for learning
No it isn't, less needs to be learned. You could think of the
non-@ variants as deprecated.
Except that they wouldn't be. It would be completely up to
programmers to use one or the other. So, anyone using D would
have to be familiar with both. And _not_ having @ is what all
existing code does and what many programmers will prefer. So,
best case, both would be very common, and there's a decent chance
that the @ versions would always be in the minority. Changing
them only works if you force the change, which means _actually_
deprecating and removing the non-@ versions and breaking most D
programs in the process.
and it's terrible for collaboration.
No more so than deciding on a variable naming or brace style.
Except that we don't need to add yet another coding standard
issue to argue over. This does _nothing_ except maybe improve
your ability to have aesthetically pleasing code if you think
that slapping @ on all of the attributes is aesthetically
pleasing (and a number of folks think that the @s are downright
ugly). Let's please not add optional syntax to the language over
an aesthetic issue.
If we could agree on a set of changes to make that made all of
this consistent, and we were willing to pay the cost of the
breakage that would result, then that would be one thing, but
optional syntax that looks like it should have a semantic
difference when it doesn't is just going to make the confusion
and questions worse, and it will add more fuel to the fire in
code style arguments.
If you want to eliminate inconsistency while only paying the
cost of breakage once, then how about this:
Let # be a character, distinct from @, such that no legal
identifier can begin with #. Then introduce a new set of
keywords #pure, #nogc, #const, #nothrow etc, which can be used
as attributes. Deprecate the previous syntax. After this
language designers can add as many #attribute keywords as they
want in the future, since they will never clash with users'
identifiers by definition.
Except that most of us _don't_ want to break our code over this.
It's not worth it. @ is ugly. # is ugly. Both add unecessary
characters. Aesthetically speaking, it would be _way_ better ts
have them all be keywords, but we didn't want to have that many
keywords. And regardless, changing code over what attributes are
named really dosen't add much value. Sure, it would be nice to
not have to explain to newbies why some attributes have @ and
some don't. Having more consistency with regards to @ would be
nice. But at this point, it is _not_ worth breaking code over And
I would be stunned if you could convince Walter or Andrei that it
is. This is _exactly_ the sort of change that they think is
detrimental to the language. It's an aesthetic issue, not a
technical one. It doesn't cause problems beyond the fact that it
spmetimes has to be explained to newbies, because they figure
that the @ must mean something, when it really doesn't. And
changing what we do with @ would arguably make the language
_less_ visually appealing. So, it's not like we even all agree
that such a change is even nice in principle. If we all had full
agreement on a new syntax and that it was worth breaking our code
over, then maybe, but you're not going to get any kind of
consensus on what the syntax should be let alone on the change
being worth the breakage.
- Jonathan M Davis
