On Saturday, 21 June 2014 at 20:48:41 UTC, Brian Schott wrote:
> I think the proposal said that the type constructors would be exempt, You wouldn't have @const but you would have @final.

I think you needed to underline this part better. This is indeed extremely important, and that is the reason for people complaining about your DIP being only "just moving inconsistencies around"

On Friday, 20 June 2014 at 22:01:31 UTC, Timon Gehr wrote:
> On 06/20/2014 09:22 PM, 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.
>
> Why not make the built-in attributes proper symbols instead and use
>
> alias Seq(T...)=T;
> alias spiffy = Seq!(pure,nothrow,safe);
>
> float mul(float a, float b) @spiffy{ }
>
> ?
>
> This will also allow use cases such as passing attributes by alias.

I think this would make the language a lot cleaner, and can be taken even further:

  @extern("C++", "some.namespace")
  class C {
    @private int x;
  }

Here `extern` is a regular function that returns an instance of some compiler-defined type. This makes "built-in" attributes just particular cases of properties (that happen to be recognized by the compiler).

"Attribute" and "property" are pretty much synonyms in English, and it always seemed strange to me that D had to define them as different--yet confusingly similar--entities.

On Sun, 22 Jun 2014 00:12:20 +0000
Mason McGill via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> "Attribute" and "property" are pretty much synonyms in English, and it always seemed strange to me that D had to define them as different--yet confusingly similar--entities.

They're not even vaguely similar in D. A property is a member of a struct or class which is a variable or a function which emulates a variable, whereas attributes are annotations put on symbols (currently just classes, structs, and functions AFAIK) which indicate extra information to the compiler and to type introspection.

So, while I can see why you might dislike the fact that attribute and property do not mean the same thing in D, they're _not_ at all similar it how they're used, so I find it very odd if anyone is confusing them. And it's not like D pioneered these meanings for attributes and properties. C# uses them for the same things.

- Jonatahn M Davis

On Sat, 21 Jun 2014 20:48:40 +0000
Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Saturday, 21 June 2014 at 19:41:42 UTC, Jonathan M Davis via Digitalmars-d wrote:
> > And to add to that, this proposal doesn't even make things
> > consistent. You
> > _still_ have to explain why some attributes have @ and some
> > don't. It's just
> > that now two of them have @ whereas they didn't before. final,
> > static, public,
> > const, etc. all still don't have @, and they're all function
> > attributes too.
>
> I think the proposal said that the type constructors would be exempt, You wouldn't have @const but you would have @final.

I thought that it called out pure and nothrow explicitly. I'll have to reread it.

> > So, it doesn't increase consistency. It just moves it around.
> > And then we have
> > to explain why some older code or tutorials _don't_ have @ on
> > pure or nothrow,
> > making it so that we have _more_ to explain.
>
> We can either say "It used to be inconsistent, but then we did nothing", or "It used to be inconsistent, but then we fixed it. Run this tool on your code and you'll be fine."

But as far is I can tell, this doesn't even make the language consistent.  It just moves the inconsistencies around.

> > I appreciate the sentiment of wanting to clean things up and
> > make them more
> > consistent, but I really don't think this does that. If we want
> > that, we'd
> > either have to add @ to all attributes or remove it from all
> > attributes. But
> > then of course, we'd have stuff like @public and @static, which
> > is
> > inconsistent with other languages and would probably cause
> > folks to complain
> > about unnecessary inconsistencies with othe languages. So, I
> > really don't
> > think that we can avoid this problem. It's just a question of
> > which form of it
> > we want to deal with and how much code breakage we're willing
> > to put up with
> > to get it there.
>
> Why is D being consistent with other languages a more important goal than D being consistent with D?

It's not, but there _is_ a cost to making it less consistent with other languages, especially when it's _currently_ consistent with them. And it's definitely not worth becoming inconsistent with other languages IMHO if you're not actually fixing the inconsistencies in D at the same time. We either need to make attributes _completely_ consistent, or there's no point in changing any of them. And that would mean either putting @ on the front of _all_ of them or _none_ of them, not simply adding @ to a few of them.

- Jonathan M Davis

On Sunday, 22 June 2014 at 05:18:05 UTC, Jonathan M Davis via Digitalmars-d wrote:
> On Sun, 22 Jun 2014 00:12:20 +0000
> Mason McGill via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> "Attribute" and "property" are pretty much synonyms in English,
>> and it always seemed strange to me that D had to define them as
>> different--yet confusingly similar--entities.
>
> They're not even vaguely similar in D. A property is a member of a struct or
> class which is a variable or a function which emulates a variable, whereas
> attributes are annotations put on symbols (currently just classes, structs,
> and functions AFAIK) which indicate extra information to the compiler and to
> type introspection.
>
> So, while I can see why you might dislike the fact that attribute and property
> do not mean the same thing in D, they're _not_ at all similar it how they're
> used, so I find it very odd if anyone is confusing them. And it's not like D
> pioneered these meanings for attributes and properties. C# uses them for the
> same things.
>
> - Jonatahn M Davis

I was referring to the `Property` and `PropertyIdentifier` entities in the D grammar (http://dlang.org/attribute.html), which are special cases of attributes. "New-style" attributes, like "property", "safe", and "nogc", are `PropertyIdentifier`s and need to be written with the "@" character. Older, non-property attributes, like "pure" and "nothrow", do not.

Sorry if this wasn't clear in the former post.

On Sun, 22 Jun 2014 05:49:33 +0000
Mason McGill via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I was referring to the `Property` and `PropertyIdentifier` entities in the D grammar (http://dlang.org/attribute.html), which are special cases of attributes. "New-style" attributes, like "property", "safe", and "nogc", are `PropertyIdentifier`s and need to be written with the "@" character. Older, non-property attributes, like "pure" and "nothrow", do not.
>
> Sorry if this wasn't clear in the former post.

That _is_ kind of an ugly use of the word property.

- Jonathan M Davis

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 would point out that if we do this, we should serious consider renaming pure to @noglobal rather than @pure, or even making it the default and then adding @global. That would make it so that we wouldn't have to keep explaining about how pure has very little to do with functional purity.

- Jonathan M Davis

On Sat, 21 Jun 2014 22:07:22 -0700
Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Sat, 21 Jun 2014 20:48:40 +0000
> Brian Schott via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> > Why is D being consistent with other languages a more important goal than D being consistent with D?
>
> It's not, but there _is_ a cost to making it less consistent with other languages, especially when it's _currently_ consistent with them. And it's definitely not worth becoming inconsistent with other languages IMHO if you're not actually fixing the inconsistencies in D at the same time. We either need to make attributes _completely_ consistent, or there's no point in changing any of them. And that would mean either putting @ on the front of _all_ of them or _none_ of them, not simply adding @ to a few of them.

And actually, the more that I think about this, the less that I like the idea. It's bad enough that we have @safe, @property, etc., but having to put @ on all of the attributes? I don't want to have @public, @static, @final etc. It's just ugly and more verbose.

I'd much rather just put up with having to explain to people that we didn't want to add new keywords and that that's why @safe, @trusted, @system, @property, and @nogc have @ on them and nothing else does - i.e. it's pretty much purely a question of age. Sure, the inconsitency sucks, but I think that it would suck more to have to have @ everywhere. I wouldn't mind having @safe and company changed to keywords to make the attributes consistent, but I very much doubt that that would be acceptable at this point.

- Jonathan M Davis

On Sunday, 22 June 2014 at 06:37:22 UTC, Jonathan M Davis via Digitalmars-d wrote:
> On Sat, 21 Jun 2014 22:07:22 -0700
>
> I'd much rather just put up with having to explain to people that we didn't
> want to add new keywords and that that's why @safe, @trusted, @system,
> @property, and @nogc have @ on them and nothing else does - i.e. it's pretty
> much purely a question of age. Sure, the inconsitency sucks, but I think that
> it would suck more to have to have @ everywhere. I wouldn't mind having @safe
> and company changed to keywords to make the attributes consistent, but I very
> much doubt that that would be acceptable at this point.
>
> - Jonathan M Davis

+1

---
Paolo

On 06/22/14 08:26, Jonathan M Davis via Digitalmars-d wrote:
> I would point out that if we do this, we should serious consider renaming pure to @noglobal rather than @pure, or even making it the default and then adding @global. That would make it so that we wouldn't have to keep explaining about how pure has very little to do with functional purity.

1) "@noglobal" is probably not the best name; unfortunately I can't think of a
   good one...
2) Making it the default, when there are no safe escape hatches, would make
   things worse. You'd often end up having to go back and add '@global'
   annotations to the whole call stack, once it turns out to be necessary
   to use some D-impure code. Which can affect already published APIs etc.

artur