+1
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis
wrote:
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_1b783fd49bfbf2c034...@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
