Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Monday, April 18, 2016 20:49:45 jmh530 via Digitalmars-d wrote:
> As an aside, the reason for not having function attribute
> inference everywhere is that it doesn't work when function bodies
> are not available. How common is this? I feel like I never write
> functions like this. Why not just make the rule that if the
> function body is available, then inference will happen?

There is no guarantee that the source code will be available, so the
attributes cannot be infered in the general case. In addition, if you don't
make the attributes explicit, you have the problem that you have no idea
which attributes apply to a function, which makes managing them harder and
on some level defeats the purpose of having them. Another major problem is
that if the attributes aren't explicit, then it's far easier to accidentally
break code by accidentally changing the attributes. We pretty much had to
add attribute inference to the language to make attributes and templates
work together (since which attributes will work is often dependent on the
template arguments), but normal functions don't need that inference.

I would strongly argue that it's bad practice to rely on attribute inference
when it's not required - even with templated functions. I'd even go so far
as to argue that using labels like

@safe:

or blocks like

@safe
{
}

is generally bad practice, because it makes it harder to figure out which
attributes apply to a given function, and while it might be nice to save on
typing those extra characters for the attributes, you're causing more work
for anyone who has to maintain those functions later - including yourself -
because it's not immediately clear which attributes apply.

- Jonathan M Davis

Re: DIP64: Attribute Cleanup

[Marco Leise via Digitalmars-d]

Am Mon, 18 Apr 2016 20:49:45 +
schrieb jmh530 :

> As an aside, the reason for not having function attribute 
> inference everywhere is that it doesn't work when function bodies 
> are not available. How common is this? I feel like I never write 
> functions like this. Why not just make the rule that if the 
> function body is available, then inference will happen?

Just because you don't know about it doesn't mean it's
non-existent. ;)
Imagine we had LibreOffice and Gtk+ or some other library with
many dependencies written in D. But even Phobos is a good
start. If all function bodies were available for attribute
inference that would start a cascade that requires the
compiler to perform semantic analysis on all of LibreOffice,
Gtk+ and whatever else is imported. It goes without further
explanation that this doesn't scale and .di files have to be
used at library boundaries.

-- 
Marco

Re: DIP64: Attribute Cleanup

[jmh530 via Digitalmars-d]

On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:


@default = @safe @nogc @pure

int foo(int i) { ... } // This function is @safe @nogc @pure
int bar(int i) @pure { ... }  // This function is only @pure



Why not just put
@safe @nogc pure:
at the top? I feel like @default would really only help if you 
want to write

int foo(int i) @default { ... }

All things equal, I would probably prefer it as an alias
alias @default = @safe @nogc pure;

The biggest downside with this approach is that there's not 
enough attributes. For instance, you can't write

int bar(int i) @system @gc { ... }
While @system already exists, @gc doesn't. I believe this has 
also been discussed before on NG.


As an aside, the reason for not having function attribute 
inference everywhere is that it doesn't work when function bodies 
are not available. How common is this? I feel like I never write 
functions like this. Why not just make the rule that if the 
function body is available, then inference will happen?

Re: DIP64: Attribute Cleanup

[Basile B. via Digitalmars-d]

On Monday, 18 April 2016 at 19:57:42 UTC, cym13 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.


Two years after, I think #1 would be a bad idea.

About #2... come on, let's do it, consistency is a gift for the 
future. Of course code will break but it looks easy enough to 
fix.


same, I neither do care about attribute sets but I'd like to see 
all function attributes will @. Even with an abnormaly long 
deprecation cycle if it's necessary, not to afraid those who 
wants to remain in their comfort zone.

Re: DIP64: Attribute Cleanup

[cym13 via Digitalmars-d]

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.


Two years after, I think #1 would be a bad idea. I think it would 
overcomplicate most code for little benefit. Attributes aren't 
things that are easy to rally under a common name. Let's say that 
most people create their own set with "@safe @nogc @pure"... what 
should it be called? "@my_project_default"? Is there a name that 
would fit most projects so that many people can reuse it? Or will 
it have a different name for every project? In that case, not 
only would it complicate code reading, but what about mixing 
them? I foresee a *big* lot of issues with that for little 
benefit.


However I do think that the current state of attributes is too 
complicated too.


My take is that most people put the same attributes to almost 
every functions in a module because those functions are meant to 
work together. Therefore I think it would be more interesting to 
be able to set a new default for the module:


@default = @safe @nogc @pure

int foo(int i) { ... } // This function is @safe @nogc @pure
int bar(int i) @pure { ... }  // This function is only @pure

I haven't of course gotten to the point where I'm able to write a 
DIP but I think it's worth a thought. Attributes look heavy when 
they're repeated. Setting a default value is the thing to do 
because it's what would be done with sets anyway, and it makes 
functions that do not follow the default rule look more imposant 
which is good: anything aside normality should be well-advertised.


About #2... come on, let's do it, consistency is a gift for the 
future. Of course code will break but it looks easy enough to fix.

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[jmh530 via Digitalmars-d]

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?

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Basile B. via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Satoshi via Digitalmars-d]

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?

Re: DIP64: Attribute Cleanup

[Nordlöw via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Nick Treleaven via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Anonymous5 via Digitalmars-d]

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 (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.c...@nowhere.fi

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Sun, 22 Jun 2014 05:49:33 +
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

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Fri, 20 Jun 2014 19:22:02 +
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

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Paolo Invernizzi via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Artur Skawina via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Shammah Chancellor via Digitalmars-d]

On 2014-06-21 19:33:44 +, 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

Re: DIP64: Attribute Cleanup

[Artur Skawina via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Kapps via Digitalmars-d]

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).

Re: DIP64: Attribute Cleanup

[Peter Alexander via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Brian Rogoff via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Peter Alexander via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Shammah Chancellor via Digitalmars-d]

On 2014-06-20 19:22:02 +, 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);

Re: DIP64: Attribute Cleanup

[Temtaime via Digitalmars-d]

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 !

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Fri, 20 Jun 2014 19:22:02 +
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

Re: DIP64: Attribute Cleanup

[Chris Cain via Digitalmars-d]

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)

Re: DIP64: Attribute Cleanup

[Chris Cain via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[francesco cattoglio via Digitalmars-d]

On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
And it's C++ that shows that almost all of D attributes are not 
necessary.


How so?

Anyway, I totally agree that attributes NEED cleanup, it really 
makes zero sense to have some without @ annotation. Really, 
keep Scott's talk in mind! :P


About code breakage: a sane deprecation path and an automated 
tool to make the code up-to-date will make sure there is zero 
discomfort for D users.


The alias for the @attribute set seems a very nice syntax to me.

Re: DIP64: Attribute Cleanup

[bearophile via Digitalmars-d]

Temtaime:


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.


And C shows that most C++ features are not necessary. You can 
implement OOP manually, etc.


Bye,
bearophile

Re: DIP64: Attribute Cleanup

[Temtaime via Digitalmars-d]

We can try to emulate it, yes. But it results in bug-prone and 
'll ugly.

C++ gives more comfortable ways to implement things.

And attributes - it's only restrictions and gives almost nothing.
If you  don't want to play with pointers - just don't do it 
instead of writing @safe etc.

Re: DIP64: Attribute Cleanup

[bearophile via Digitalmars-d]

Temtaime:

If you  don't want to play with pointers - just don't do it 
instead of writing @safe etc.


This is the C approach to programming, that has worked well 
enough for many years. Give the programmers all the sharp tools 
and let them sort out their usage and to follow sufficient safety 
measures. The result is an industry of code verifiers, tight code 
that runs fast, but sometimes fails very badly.


Another approach is visible in Ada/Rust, safety on default 
enforced by the type system and the annotations. Ada works very 
well for its high integrity niche, while Rust is still unproven, 
but looks promising.


D seems to follow an intermediate route. It's still not as safe 
as Ada/Rust, but it's somewhat safe and Walter shows that he 
wants D to become safer in future.


Bye,
bearophile

Re: DIP64: Attribute Cleanup

[Chris Cain via Digitalmars-d]

On Saturday, 21 June 2014 at 18:20:43 UTC, Temtaime wrote:
And attributes - it's only restrictions and gives almost 
nothing.


I'll reiterate that the restrictions in question make code easier 
to reason about. Increased reasoning is not almost nothing ... 
in fact, that's one of the main benefits of having any 
abstractions at all.


If you  don't want to play with pointers - just don't do it 
instead of writing @safe etc.


I think if you'd like a discussion about the values of the 
various attributes, you should create a topic about it. This 
topic should really only relate to this DIP.


But FWIW, if what you said was truly sufficient, then there 
wouldn't be nearly as many bugs in C++ codebases as there are. 
Furthermore, there wouldn't be D, Go, Rust, Haskell, etc. and/or 
they wouldn't be found to be valuable by anyone.

Re: DIP64: Attribute Cleanup

[Temtaime via Digitalmars-d]

I think you misunderstood me.
I didn't say that C++ is useless and C can do all the things.
I spoken only about attributes.

D gives much more static checks and other great things.
And i'm unsure only at necessity of all these attributes.

In all my code i really uses only  const ,  immutable  and  
@property .

Re: DIP64: Attribute Cleanup

[Artur Skawina via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Sat, 21 Jun 2014 17:54:33 +
Peter Alexander via Digitalmars-d digitalmars-d@puremagic.com wrote:

 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.

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.
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.

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.

- Jonathan M Davis

Re: DIP64: Attribute Cleanup

[H. S. Teoh via Digitalmars-d]

On Sat, Jun 21, 2014 at 12:41:26PM -0700, 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.  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.
 
 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.
[...]

Maybe we should be considering *removing* @ from @safe and @nogc? But I
don't see that flying either, since it can well conflict with existing
user-defined identifiers.

OTOH, I think there is some distinction between, say, pure and public,
because pure is something that can be inferred, and it involves
restricting the set of allowed code in the body of the function
(likewise with nothrow, @safe, @nogc), whereas public merely affects
external access to the function. The latter can't be inferred
automatically (and it doesn't make sense to do so), but the former can.
Furthermore, in the former case, it makes sense for a function's
attributes to depend on its arguments -- e.g., opApply can be pure if
the delegate argument is pure, but it doesn't make sense for opApply to
be public/protected/private just because its argument is.

So there's at least some amount of rationale for treating the two
categories of attributes differently.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

Re: DIP64: Attribute Cleanup

[Brian Schott via Digitalmars-d]

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.


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.


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?

Re: DIP64: Attribute Cleanup

[francesco cattoglio via Digitalmars-d]

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

Re: DIP64: Attribute Cleanup

[Mason McGill via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Sun, 22 Jun 2014 00:12:20 +
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

Re: DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Sat, 21 Jun 2014 20:48:40 +
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

Re: DIP64: Attribute Cleanup

[Mason McGill via Digitalmars-d]

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

DIP64: Attribute Cleanup

[Brian Schott via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[H. S. Teoh via Digitalmars-d]

On Fri, Jun 20, 2014 at 07:22:02PM +, Brian Schott via Digitalmars-d 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.

And while we're at it, why not also fix holes in attribute semantics on
top of just fixing syntax?

First, there is no way to mark a function as *impure* as opposed to pure
(leaving out pure is not an option in template functions due to
automatic attribute inference). Also, there's an inconsistency between
positive attributes (pure, safe) vs. negative attributes (nothrow,
nogc). So ideally, the new syntax should allow you to specify both pure
and impure, and ideally, it should not special-case on peculiarities of
the English language (pure/impure vs. throw/nothrow). So it should be
something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., for
maximum consistency.

I also like your attribute sets idea. This could be the solution we're
looking for with transitive attributes (aka inout(pure), inout(nothrow),
etc.). If there was some syntax for attribute set intersection, say
@a*@b, then we could specify that the attribute set of some given
function f() is the intersection of the attribute sets of its input
delegates. For example:

// This is hypothetical syntax, I'm sure you can think of a
// better way to write this.
int dgCaller(int delegate(int) @a dg1, int delegate(int) @b dg2)
@this = @a*@b // specifies that this function's
  // attributes is the intersection of @a and @b
{
if (someCondition)
return dg1(1);
else
return dg2(2);
}


T

-- 
Heads I win, tails you lose.

Re: DIP64: Attribute Cleanup

[Meta via Digitalmars-d]

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.


Does this work for all attributes? For example:

@OneTo5 = @(1) @(2) @(3) @(4) @(5);


And will this be possible?

struct Test
{
string str;
}

@Tattr(str) = @Test(str);
@Tattr = @Test();

Re: DIP64: Attribute Cleanup

[Brad Anderson via Digitalmars-d]

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 like it.

Just thinking aloud, it could be interesting to allow compile 
time logic of some sort (both on the arguments and on the symbol 
the attribute is being attached to).


Contrived example borrowing template syntax (which could almost 
certainly be improved upon):


template @pureIfNameHasPure(Sym) {
static if(__traits(identifier, Sym).canFind(Pure))
alias @pureIfNameHasPure = @pure;
else
alias @pureIfNameHasPure = /* nothing...not sure how to 
show that */;


}

Re: DIP64: Attribute Cleanup

[Gary Willoughby via Digitalmars-d]

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.


They do need standardising but i don't like the idea of attribute 
sets. Attribute sets would make attributes too over complicated 
to understand. Attributes need to be simple and concise which i 
think they already are.

Re: DIP64: Attribute Cleanup

[w0rp via Digitalmars-d]

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.


It may be worth splitting things up a little, or perhaps the 
extra parts in the DIP are your 'duck.' Because I think 
normalising every attribute to @ syntax is good. I look at it and 
think, Yeah, good. Especially so if it also means that user 
defined attributes can also be on both sides of a function 
signature, as that would ease transition between different 
versions of the language.


I think the parts in the DIP about the exact semantics or syntax 
for composing attributes will be debated a bit, but the Let's 
just put @ in there part is pretty straightforward.

Re: DIP64: Attribute Cleanup

[Brian Schott via Digitalmars-d]

On Friday, 20 June 2014 at 19:48:49 UTC, H. S. Teoh via 
Digitalmars-d wrote:
First, there is no way to mark a function as *impure* as 
opposed to pure
(leaving out pure is not an option in template functions due 
to
automatic attribute inference). Also, there's an inconsistency 
between
positive attributes (pure, safe) vs. negative attributes 
(nothrow,
nogc). So ideally, the new syntax should allow you to specify 
both pure
and impure, and ideally, it should not special-case on 
peculiarities of
the English language (pure/impure vs. throw/nothrow). So it 
should be
something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., 
for

maximum consistency.


I can see this being useful. We'd just have to decide what it 
means to negate an attribute with arguments. (e.g. 
`@!name(bob)`)


Also in the case of @!throw we'd have to modify the definition of 
attributes to accept the throw token instead of just 
identifiers. Maybe converting nothrow to @!throws would be 
better.


I also like your attribute sets idea. This could be the 
solution we're
looking for with transitive attributes (aka inout(pure), 
inout(nothrow),
etc.). If there was some syntax for attribute set intersection, 
say
@a*@b, then we could specify that the attribute set of some 
given
function f() is the intersection of the attribute sets of its 
input

delegates. For example:

// This is hypothetical syntax, I'm sure you can think of a
// better way to write this.
	int dgCaller(int delegate(int) @a dg1, int delegate(int) @b 
dg2)

@this = @a*@b // specifies that this function's
  // attributes is the intersection of @a and @b
{
if (someCondition)
return dg1(1);
else
return dg2(2);
}


T


Is that use case common enough to justify complicating the 
compiler?

Re: DIP64: Attribute Cleanup

[Steven Schveighoffer via Digitalmars-d]

On Fri, 20 Jun 2014 15:47:07 -0400, H. S. Teoh via Digitalmars-d  
digitalmars-d@puremagic.com wrote:


On Fri, Jun 20, 2014 at 07:22:02PM +, Brian Schott via Digitalmars-d  
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.


And while we're at it, why not also fix holes in attribute semantics on
top of just fixing syntax?

First, there is no way to mark a function as *impure* as opposed to pure
(leaving out pure is not an option in template functions due to
automatic attribute inference). Also, there's an inconsistency between
positive attributes (pure, safe) vs. negative attributes (nothrow,
nogc). So ideally, the new syntax should allow you to specify both pure
and impure, and ideally, it should not special-case on peculiarities of
the English language (pure/impure vs. throw/nothrow). So it should be
something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., for
maximum consistency.


I like the idea, but seeing as how attribute sets already take arguments,  
it's natural to add them to builtins:


@pure(true) == @pure
@pure(false) == not @pure

-Steve

Re: DIP64: Attribute Cleanup

[Steven Schveighoffer via Digitalmars-d]

On Fri, 20 Jun 2014 15:22:02 -0400, Brian Schott briancsch...@gmail.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 like it.

At first, I thought hm.., every project is going to have their own  
definition for @safe @pure @nothrow, but we can put one in druntime  
common sets that everyone should use, and we already allow custom  
attributes anyway that have to be looked up.


One thing this will make slightly more difficult is looking for e.g.  
@trusted functions, because you can't just grep for them. However, I think  
with DScanner, you can probably find things easy enough.


2 thoughts:

1. On H.S.Teoh's idea to add negation, what does foo() @pure !@pure mean  
(or if my preferred syntax was accepted, @pure @pure(false) )?

2. What does this print?

@myattr = @safe @pure;

void foo() @myattr {}

pragma(msg, (foo).typeof);

-Steve

Re: DIP64: Attribute Cleanup

[Timon Gehr via Digitalmars-d]

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.

Re: DIP64: Attribute Cleanup

[Philpax via Digitalmars-d]

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