[Issue 13388] accept '@' before 'nothrow' and 'pure'

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Tue Sep 2 01:15:57 PDT 2014


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

--- Comment #28 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to Don from comment #27)
> >(In reply to Jonathan M Davis from comment #14)
> >> I really think that we've passed the point where it's worth fixing it.
> 
> NO!!!! This attitude is the biggest problem D has.
> Please, watch Scott Meyer's talk again. "Most D code is yet to be written".
> The future benefits of fixing this kind of crap, are huge. And this one
> doesn't even break any existing code.
> 
> Omitting the @ from pure and nothrow was heavily criticized at the time. It
> was known to be a stupid decision. Two things have changed since then:
> 
> (1) We now have UDAs.
> (2) @property is gone.

@property isn't gone. Kenji has been doing work on fixing it up, and in the
end, we should end up in the situation where @property makes it so that parens
are illegal, and parens are optional for non- at property functions with no
arguments.

Regardless, I don't see any way that changing which attributes have @ on them
and which don't is going to make it consistent unless you put @ on all of them,
or you don't put it on any of them. So, either we end up with safe, trusted,
system, and property, or we end up with stuff like @public, @const, and @static
- which would be hideous IMHO. So, it seems to me that no matter which way we
go, we end up with something that's ugly in some way or another, so I see no
reason to change it. We'd just be moving the ugliness and inconsistency around.
As it is, a very small percentage of the attributes have @ on them, which I
think is a good thing. I'd much rather leave @ for UDAs.

Regardless, for anything like this to happen, you'd have to convince Walter,
and this is exactly the sort of thing he's likely to say no to because it
doesn't have any real practical, technical benefit. At best, it just makes it
easier for newbies to figure out whether @ goes on the front of an attribute or
not, and unless you put @ on _all_ of them, I don't think that it really even
does that. So, you're going to have a very hard time convincing him. I expect
that he'll see it as useless shuffling around that will break code for no real
benefit.

- Jonathan M Davis

--


More information about the Digitalmars-d-bugs mailing list