accept @pure @nothrow @return attributes

[Atila Neves via Digitalmars-d]

+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_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