On 2014-06-21 19:33:44 +0000, Artur Skawina via Digitalmars-d said:

> On 06/21/14 19:56, Shammah Chancellor via Digitalmars-d wrote:
>> I like it, but I think the attribute sets should be based on then alias syntax though.
>> 
>> alias @attributeSet = (@attribute1, @attribute2, @attribute3);
> 
> Well, D does not have that kind of tuple syntax and introducing one for
> this special case wouldn't be a good idea. Other than that, this feature
> already exists, only it's currently limited to user defined attributes.
> The present syntax looks like this:
> 
>    alias Tuple(A...) = A;
>    alias attributeSet = Tuple!(attribute1, attribute2, attribute3);
> 
> and is already usable with UDAs and "magic" attributes:
> 
>    version (GNU) {
>    static import gcc.attribute;
>    enum noinline = gcc.attribute.attribute("noinline");
>    }
> 
>    struct other_attribute {}
> 
>    alias Tuple(A...) = A;
> 
>    alias spiffy = Tuple!(other_attribute, noinline);
> 
>    @spiffy int f(int a) { return a+a; }
> 
> I'm not sure inventing another syntax is necessary.
> 
> (Making the built-in (keyword) attributes less special is of course
> the hard part, but the choice of syntax shouldn't really affect that)
> 
> artur

So, basically we don't need special syntax for attribute sets, we just need to make it so built-in attributes are not "special?"

-Shammah

On 06/22/14 14:18, Shammah Chancellor via Digitalmars-d wrote:
> 
> So, basically we don't need special syntax for attribute sets, we just need to make it so built-in attributes are not "special?"

I think this is one option. But exposing them as symbols w/o breaking too much existing code will not be trivial. Also, the parametrization and negation issues should probably be addressed at the same time, otherwise even more not fully backwards compatible changes may be necessary in the future.

artur

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.

@exhumation

So, two years after ?
If attributes are well split into sub categories, we could justify that a sub category will have @ and another not (e.g protection attributes: not @, functions attributes: @).

The list of attributes that's not classified is:

+ static
 extern
+ abstract
+ final
+ override
+ synchronized
+ auto
 scope
+ const
+ immutable
 inout
+ shared
 __gshared
+ nothrow
+ pure
 ref

possible categories:
- function attributes: nothrow, pure
- function member attributes: function attributes + abstract, final, override, static, synchronized , const , shared
- type modifier attributes (+ return type attributes)

function attributes and function member attributes can be replaced by a @ version.
function attributes that are also type attributes will also have a new @version but obsiously the not-@ version will always remain for <attribute>(T).

type modifier attributes won't have a @version because otherwise the goal of DIP is not reach (fix inconsistence for const for example which can have up to 3 different meaning now).

This would reduce "the hell" a bit.

---
rb.cssp@nowhere.fi

On Sunday, 17 April 2016 at 12:05:03 UTC, Anonymous5 wrote:
> If attributes are well split into sub categories, we could justify that a sub category will have @ and another not (e.g protection attributes: not @, functions attributes: @).
>
> The list of attributes that's not classified is:
>
> + static
>  extern
> + abstract
> + final
> + override
> + synchronized
> + auto
>  scope
> + const
> + immutable
>  inout
> + shared
>  __gshared
> + nothrow
> + pure
>  ref

Only override, nothrow and pure apply only to functions. Like the existing @attributes, all function-only attributes should use @attribute syntax. We only have to change 3, and the existing keywords can still be supported indefinitely IMO.

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.

Nice. I like it.

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.

Language defined attribs should be without @ and user defined attribs with @

Whats wrong with it?

On Monday, 18 April 2016 at 10:32:39 UTC, Satoshi wrote:
> 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.
>
> Language defined attribs should be without @ and user defined attribs with @

It's already not the case with @safe, @trusted, @system and @nogc. They are not UDAs, they are defined in the language but they start with @.

> Whats wrong with it?

- some attributes are also storage classes or type constructors (like const).
- It looks strange when you learn.
- It's confusing.
- It's inconsistent in editors (lexing doesn't tells you what const is)

If new attributes are added they'll always be @something because there's already too much keywords in D.

The first item in the list is interesting because people at the beginning often think that

      const int foo(){}

returns a const(int), which is not the case. Here `const` is a function attribute, not a type constructor.

The most insane case:

    const(int) foo(const int a) const
    {
       return 0;
    }

Here it should be clear that const as a function attribute should be replaced by @const.

On Monday, April 18, 2016 10:32:39 Satoshi via Digitalmars-d wrote:
> 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.
>
> Language defined attribs should be without @ and user defined attribs with @
>
> Whats wrong with it?

We started putting @ on attributes to avoid adding new keywords before we even had user-defined attributes in the language.  Hopefully, we don't need to add any new keywords, but if we do, we'd almost certainly do it with @ in order to actually avoid adding another keyword. Certainly, your suggestion is by far the most sensible from the standpoint of making it easy to figure out which attributes start with @ and which don't, but it would cost more keywords than we want to pay.

Regardless, changing any of the attributes now would break a _lot_ of code, and such a change would have to be worth the pain that it would cause, which is questinonable. There isn't a consensus on what they should be changed to (pretty much any change except what you suggested results in inconsistencies in which ones are prepended with @ and which aren't - it's just a different set of inconsistencies that we have now, and that arguably defeats the whole purpose of making the change). There are definitely vocal folks who want the attributes changed in order to make them more consistent, but as long as it's not clear what they should be changed to, it'll never happen, and Walter and Andrei aren't big fans of renaming stuff just to make it more consistent. It carries a definite cost in terms of code breakage, and it's highly debatable as to whether it's worth it. So, I don't expect that the attributes are ever going to get renamed, though if someone can come up with a good enough scheme and somehow persuade Walter, then maybe it would happen. I'm not holding my breath though.

- Jonathan M Davis

On Monday, 18 April 2016 at 12:11:46 UTC, Jonathan M Davis wrote:
>
> Regardless, changing any of the attributes now would break a _lot_ of code, and such a change would have to be worth the pain that it would cause, which is questinonable.

dfix has a DIP64 switch, right?

On Monday, April 18, 2016 13:10:59 jmh530 via Digitalmars-d wrote:
> On Monday, 18 April 2016 at 12:11:46 UTC, Jonathan M Davis wrote:
> > Regardless, changing any of the attributes now would break a _lot_ of code, and such a change would have to be worth the pain that it would cause, which is questinonable.
>
> dfix has a DIP64 switch, right?

Yes, because the person who created DIP64 created dfix. But there is no consensus that DIP64 should be adopted, and based on how Walter has typically responded to changes that will break code, I very much doubt that having dfix make the change easy would be sufficient for him to decide that the code breakage that would result from changing the attributes would be acceptable.

Honestly, I think that DIP64 is a poster boy for unnecessary churn. Sure, in theory, it would be nice to make the attributes more consistent, but ultimately, it's yet another case of renaming stuff without actually adding or otherwise changing functionality. We got enough screaming when we made changes like that 5 years ago even though they did make Phobos more consistent. And a _lot_ more code has been written since then. So, that much more code will be affected by such a change whether the change is theoretically desirable or not. And while having a tool to make the change relatively easy definitely helps, it doesn't eliminate the cost of the change. It just reduces it. Personally, I think that we're well past the point where doing renaming like this is worth it - especially with the language itself.

- Jonathan M Davis