accept @pure @nothrow @return attributes

[Jonathan M Davis via Digitalmars-d]

On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
> wrote:
> > inconsistencies and annoying points in the language. And much
> > of the time,
> > those inconsistencies and annoying points are forced by other
> > aspects of the
> > language that actually make things nice and clean. There are
> > always
> > tradeoffs, and often, there is no clear, right answer to how it
> > should be.
>
> I think I misinterpreted what you meant to say, but if the
> semantics are good and sound then you should be able to device a
> consistent syntax for the language that is in line with current
> terminology in comp sci (even if that means pointing to Wikipedia
> for a definition of the term).
>
> That would of course mean a lot of changes to D terminology:
>
> "const" => "readonly"
> "enum" => "const"
> "range"=>"iterator"
> "pure"=>"no global effect"
> "ubyte" => "byte"
> "lazy" => "by name"
> etc...

I don't see what any of that has to do with which attributes have @ on them
or not.

The problem is that any situation where some of the attributes have @ and
some don't is going to cause some confusion, whereas putting @ on all of
them would create inconsistencies with the expectations of folks coming from
other languages and make porting code to D more annoying, and putting @ on
none of them means that we're consistent but would mean that every time
that we had to introduce a new built-in attribute (which we don't want to do
much more of, but it still happens occasionally), we would either break
existing code (because it would mean introducing a new keyword), or we'd
have to put @ on it (making things inconsistent again, but only risking
breaking UDA code, which is less prevalent).

If we could start from scratch and guarantee that no new attributes would
ever be introduced, then we could just put @ on none of them and thus be
fully consistent. But we can't start from scratch, and we can't guarantee
that there will be no new attributes. And even then, instead of getting
complaints about being inconsistent with @, then we'd get even more
complaints about the number of keywords that we have.

There is no way to win here. No matter what we do, there will be screaming
from someone. And whether the language would be objectively improved would
be debatable.

There may be set of changes that would ultimately be better enough that
they'd be worth making - where the pros are generally considered to outweigh
the cons - but we'll be stuck with the cons regardless, and I seriously
question that any change to attribute names is enough of an improvement to
merit the code breakage that it would cause, even if it were objectively
better.

- Jonathan M Davis