My understanding is that @ attributes were for used-defined behavior only.   Pure and nothrow, since the compiler implements behavior on those keywords, do not have the @ sign.   So, why is @safe, @safe, and not just "safe".

On the basis that @attributes should not have compiler defined behavior.   Please take off the @ from the @safe.   This would apply to @trusted as well.

Also,  I think that having UDAs (user defined attributes) be freeform, and not a class following some interface is asking for trouble.  It makes them hard to use reflection with, and it also causes the potential for modules to use the same literal for different purposes.  I think C# has this right.

On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:
> My understanding is that @ attributes were for used-defined behavior only.

It is all a historical thing... at first, all new things were done as keywords. Then around the time @safe came around, they were changing their minds and new things became @keywords. Then, some time after that, UDAs came around and used the @ syntax.

But the reason it is pure and @safe instead of @pure @safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.

On Thursday, 7 November 2013 at 02:04:37 UTC, Adam D. Ruppe wrote:
> On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:
>> My understanding is that @ attributes were for used-defined behavior only.
>
> It is all a historical thing... at first, all new things were done as keywords. Then around the time @safe came around, they were changing their minds and new things became @keywords. Then, some time after that, UDAs came around and used the @ syntax.

More specifically, the discussion was around properties and how to handle them. User-Defined attributes were also being thrown around, and at some point a suggestion combined the two suggesting properties be denoted with @property. Some time passed and suddenly D could parse @property on functions (@safe may have been added at the same time, or a little later). No UDA[1] was introduced.

1. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

On 2013-11-07 02:04:36 +0000, Adam D. Ruppe said:

> On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:
>> My understanding is that @ attributes were for used-defined behavior only.
> 
> It is all a historical thing... at first, all new things were done as keywords. Then around the time @safe came around, they were changing their minds and new things became @keywords. Then, some time after that, UDAs came around and used the @ syntax.
> 
> But the reason it is pure and @safe instead of @pure @safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.

There's an easy solution to that.   Put warnings on pure, nothrow, and immutable ( in the function tag context) and add @pure, @nothrow, @immutable etc.  Fix it going forward and eventually remove it.

On Wednesday, November 06, 2013 22:11:02 Shammah Chancellor wrote:
> On 2013-11-07 02:04:36 +0000, Adam D. Ruppe said:
> > On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:
> >> My understanding is that @ attributes were for used-defined behavior only.
> > 
> > It is all a historical thing... at first, all new things were done as keywords. Then around the time @safe came around, they were changing their minds and new things became @keywords. Then, some time after that, UDAs came around and used the @ syntax.
> > 
> > But the reason it is pure and @safe instead of @pure @safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.
> 
> There's an easy solution to that.   Put warnings on pure, nothrow, and immutable ( in the function tag context) and add @pure, @nothrow, @immutable etc.  Fix it going forward and eventually remove it.

And gain what? You force everyone to change their code for essentially zero benefit.

- Jonathan M Davis

Am 07.11.2013 05:45, schrieb Jonathan M Davis:
> On Wednesday, November 06, 2013 22:11:02 Shammah Chancellor wrote:
>> On 2013-11-07 02:04:36 +0000, Adam D. Ruppe said:
>>> On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:
>>>> My understanding is that @ attributes were for used-defined behavior
>>>> only.
>>>
>>> It is all a historical thing... at first, all new things were done as
>>> keywords. Then around the time @safe came around, they were changing
>>> their minds and new things became @keywords. Then, some time after
>>> that, UDAs came around and used the @ syntax.
>>>
>>> But the reason it is pure and @safe instead of @pure @safe or pure and
>>> safe is just historical accident - they were introduced in that
>>> particular phase, and now the worry is changing it will annoyingly
>>> break too much code for very little real benefit.
>>
>> There's an easy solution to that.   Put warnings on pure, nothrow, and
>> immutable ( in the function tag context) and add @pure, @nothrow,
>> @immutable etc.  Fix it going forward and eventually remove it.
>
> And gain what? You force everyone to change their code for essentially zero
> benefit.
>
> - Jonathan M Davis
>

What about gaining consitency? That was something D1 was really strong in, but D2 lost.

>
> And gain what? You force everyone to change their code for essentially zero
> benefit.
>
> - Jonathan M Davis

It's not zero benefit, although it may seem like that over a small period of time, it's over an extended period that inconsistencies can become a very significant cause of productivity loss. I'd rather fix up my old code, and I know how horrible that is especially for production code that is in use, it's just not fun, but if language stability was more important to me than productivity, I would not have made the very painful move from C/C++ to D.

--rt

On 2013-11-07 07:48, Rob T wrote:

> It's not zero benefit, although it may seem like that over a small
> period of time, it's over an extended period that inconsistencies can
> become a very significant cause of productivity loss. I'd rather fix up
> my old code, and I know how horrible that is especially for production
> code that is in use, it's just not fun, but if language stability was
> more important to me than productivity, I would not have made the very
> painful move from C/C++ to D.

I agree with you. Unfortunately the those with commit access do not agree. They have no interest, what so ever, in breaking backward compatibility due to consistency.

The result is exactly what happened with D1. At some arbitrary point in time it was decided that backwards compatibility must be kept, almost at all cost. This was decided even though the language and the standard library was far from stable.

-- 
/Jacob Carlborg

On 2013-11-07 01:13, Shammah Chancellor wrote:
> My understanding is that @ attributes were for used-defined behavior
> only.   Pure and nothrow, since the compiler implements behavior on
> those keywords, do not have the @ sign.   So, why is @safe, @safe, and
> not just "safe".
>
> On the basis that @attributes should not have compiler defined
> behavior.   Please take off the @ from the @safe.   This would apply to
> @trusted as well.

The reason is basically that they wanted a new scope for keywords. Making it easy to introduce new keywords without breaking existing code. This worked until UDA's where introduce, because now "@foo" is legal. Now we're back at square one, although we do have UDA's, which are nice :)

> Also,  I think that having UDAs (user defined attributes) be freeform,
> and not a class following some interface is asking for trouble.  It
> makes them hard to use reflection with, and it also causes the potential
> for modules to use the same literal for different purposes. I think C#
> has this right.

I completely agree. The recommendation is to not use literals but instead create a new type for the UDA:

enum foo;

@foo void bar () { }

Or:

struct foo { string name; }

@foo("asd") void bar () { }

This way you can uniquely identify a UDA using its fully qualified name. On top of that I'm using some helper functions which forces me to explicitly mark any UDA with a special UDA.

enum attribute;

@attribute enum foo;

@attribute struct foo { string name; }

@foo("asd") void bar () { }

getAttributes!(bar);

By default "getAttributes" will only return attributes which themselves have the @attribute UDA attached to them. See https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Attribute.d

-- 
/Jacob Carlborg

On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:
> My understanding is that @ attributes were for used-defined behavior only.   Pure and nothrow, since the compiler implements behavior on those keywords, do not have the @ sign.
>  So, why is @safe, @safe, and not just "safe".
>
> On the basis that @attributes should not have compiler defined behavior.   Please take off the @ from the @safe.   This would apply to @trusted as well.
>

Remove @ from @safe, @system and @trust or @property would lead to add more keywords, which would be unpleasant (break existing code and so on). More better would be to add @ sign to the others (@nothrow, @immutable and @pure).

> ...not a class following some interface is asking for trouble.

What exactly do you mean?