+1 to this proposal; as someone trying to annotate their D code appropriately, the inconsistency in the usage of @ forces me to look up the docs every time, which leads to considerable productivity loss. I'm sure it's less of an issue when one is sufficiently versed in annotation, but I find it quite annoying right now.

On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.

I agree that the lack of consistency with @ is annoying, and was especially annoying when I was starting to learn D. Having to look up every time whether you need an @ is the type of inconsistent baggage that D should not have.


I do like the idea of attribute sets, but I'm not sure if others will as it could be somewhat confusing. For example, if final(false) gets in, the first thing I would be doing is making an attribute set @virtual that just expands to @final(false) (incidentally, this would make me much less opposed to the final(false) syntax).

On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64

All things being equal, it would be nicer to have consistency, but do we really I want to break almost all existing code?

I know you've proposed a tool to do the transition, but there are lots of unmaintained projects out there that are still used, and tutorials/articles/books/university courses written using the existing syntax. Those likely won't be, or can't be changed easily.

One possible compromise might be to leave the old syntax there for legacy reasons, but allow (and encourage) @pure, @nothrow, etc.

On Saturday, 21 June 2014 at 17:11:24 UTC, Peter Alexander wrote:
> On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
>> http://wiki.dlang.org/DIP64
>
> All things being equal, it would be nicer to have consistency, but do we really I want to break almost all existing code?
>
> I know you've proposed a tool to do the transition, but there are lots of unmaintained projects out there that are still used, and tutorials/articles/books/university courses written using the existing syntax. Those likely won't be, or can't be changed easily.
>
> One possible compromise might be to leave the old syntax there for legacy reasons, but allow (and encourage) @pure, @nothrow, etc.

I completely agree with your point, but if things never get cleaned up we'll need a guy like Scott Meyers to explain the overcomplicated result. I don't know how to resolve this issue, opponents of change will claim that a language will never get traction if it changes too much too quickly, and proponents will claim that not removing inconsistencies leads to a mess. Both are right.

On Saturday, 21 June 2014 at 17:20:08 UTC, Brian Rogoff wrote:
> I completely agree with your point, but if things never get cleaned up we'll need a guy like Scott Meyers to explain the overcomplicated result. I don't know how to resolve this issue, opponents of change will claim that a language will never get traction if it changes too much too quickly, and proponents will claim that not removing inconsistencies leads to a mess. Both are right.

Like most things in engineering, there is no right answer, and there are compromises all the way. You just have to weigh up the pros and cons and make a decision. Of course, reasonable people may disagree on the weights, so some debate may be necessary.

The pros and cons are clear here. I think it would be nice to have consistent syntax and keep Scott away, but it's just syntax. It doesn't affect the expressiveness, power, or performance of the language. The cost is that it breaks almost all working code. I do not think the pros outweigh the cons, so I do not think this should go ahead, and we will just have to live with Scott explaining why some attributes have @ and others do not.

On 2014-06-20 19:22:02 +0000, Brian Schott said:

> http://wiki.dlang.org/DIP64
> 
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
> 
> I've created a DIP to address these issues.

I like it, but I think the attribute sets should be based on then alias syntax though.

alias @attributeSet = (@attribute1, @attribute2, @attribute3);

Too many attributes in D.
In C++ there is no pure, safe, trusted and others.

And it's C++ that shows that almost all of D attributes are not necessary.

Welcome to attribute hell !

On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
> Too many attributes in D.
> In C++ there is no pure, safe, trusted and others.
>
> And it's C++ that shows that almost all of D attributes are not necessary.
>
> Welcome to attribute hell !

Of course. But pure/safe/trusted/others statically verify that huge classes of errors cannot occur and make reasoning about code much easier. You're correct that it's not necessary, but they're certainly desirable in many ways.

I'd willfully trade bug hell for "attribute hell".

On Fri, 20 Jun 2014 19:22:02 +0000
Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too
> verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.

I don't know. Why single out pure and nothrow? We also have public, final, static, const, immutable, etc. all of which don't start with @. Only a very few of the attributes start with @. So, it seems to me that changing pure and nothrow to @pure and @nothrow is really just moving the inconsistency around rather than fixing it. What's the point? The result is still inconsistent, and it's still arbitrary as far as I can tell.

It's been suggested in this thread that this could help with attribute negation, but the primary attribute that we've discussed as needing to be negatable (final) is unaffected by this, so using @ as a way to lead to introducing attribute negation doesn't really work. And some of the existing @ attributes wouldn't make sense for negation (e.g. @safe), because they're part of a group of three rather than two.

And as for attribute sets, I think that they're the kind of idea that _sounds_ like a good idea but is ultimately a bad idea. Yes, having a function marked up like

auto foo() const @safe pure nothrow {...}

is annoyingly verbose, but it's _clear_, and by adding attribute sets, we'd be opening the door to make it very unclear and confusing. If anyone can declare their own attribute sets, then we could end up with as many new names for attribute combinations as there are programmers using them. One person could create @spn for @safe @pure @nothrow, whereas someone else creats @safepurenothrow, etc.

And even if we created official attribute sets for the common stuff, you're still creating a combinatorial explosion of attributes that people have to know just so that they can put one attribute on a function instead of two to four attributes.  I really don't think that that's a good tradeoff. I'd _much_ rather just leave things as they are. It may be verbose, but at least it's clear.

I already think that it's bad enough that we have in on parameters being aliased to two different storage classes - const and scope. And now we're talking about not only adding _more_ items like that but making it so that _anyone_ can define them. I think that it's a far better idea to just have one way to mark something with a particular attributer rather than to find ways to combine multiple attributes into a single attribute.

- Jonathan M Davis

On Saturday, 21 June 2014 at 18:11:32 UTC, Chris Cain wrote:
> On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
>> Too many attributes in D.
>> In C++ there is no pure, safe, trusted and others.
>>
>> And it's C++ that shows that almost all of D attributes are not necessary.
>>
>> Welcome to attribute hell !
>
> Of course. But pure/safe/trusted/others statically verify that huge classes of errors cannot occur and make reasoning about code much easier. You're correct that it's not necessary, but they're certainly desirable in many ways.
>
> I'd willfully trade bug hell for "attribute hell".

(well, "trusted" doesn't statically verify anything, it just makes it so you can manually verify the safety of the function so it can be used in safe functions, but you know what I mean)