accept @pure @nothrow @return attributes

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 26 03:39:12 PST 2015


On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/26/15 1:50 AM, Brian Schott wrote:
> > On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
> >> If someone is not following the merges, well...  [1] !!
> >>
> >> ---
> >> Paolo
> >>
> >> [1]
> >> http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171@hookshot-fe4-cp1-prd.iad.github.net.mail
> >>
> >
> > I'm running out of ideas for DConf topics.
>
> Heh, I infer that's a good thing. Nevertheless we should probably
> discuss this and its impact; don't forget we can always undo it before
> 2.067. Thoughts! -- Andrei

In theory, the increased consistency is welcome, but the increased visual
noise definitely is not.  And if we leave in pure and nothrow without @,
then we're going to have code out there doing both, which adds to the
confusion, and if we deprecate pure and nothrow without @, then we'll be
forced to change pretty much every D program in existence.

But It's not like this really improves consistency all that much anyway,
because public, protected, package, private, final, override, static, const,
immutable, inout, and deprecated all don't have @. So, most function
attributes _don't_ have @ on them, and we just added @ to some of them,
making things even _less_ consistent. In fact, priore to this, @safe,
@trusted, @system, and @property were the _only_ function attributes with @
on them. So, if we really wanted to improve consistency IMHO, we'd get rid
of @ from everything that's built-in and leave it for user-defined
attributes, but that would break existing code too.

Ultimately, I really don't see this as an improvement, because it really
doesn't fix the consistency problem with attributes, and we're either going
to have to change existing code or end up with both @pure and pure, and
@nothrow and nothrow in the language, which is just ugly. But aside from
having duplicate attributes for the same thing, I don't know that it really
makes things any worse - though at least before this, we could just say that
@property, @safe, @trusted, and @system were oddballs that were added late
in the game and that they had @, because we didn't want to add new keywords.
With this change, I expect that it will be even less clear which attributes
have @ on them and which don't.

Personally, I'd much prefer that we not make this change. It's just
shuffling things around in an attempt to make them more consistent while
actually making them _less_ consistent.

- Jonathan M Davis



More information about the Digitalmars-d mailing list