Re: DIP 1012--Attributes--Preliminary Review Round 1

[sarn via Digitalmars-d]

On Sunday, 27 May 2018 at 13:44:40 UTC, Mike Franklin wrote:
I don't know what's happening with this DIP, but I've recently 
encountered a real-world problem for which there is no 
palatable workaround that this DIP would likely solve:


https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123

My attempts to workaround the issue I posted at
https://forum.dlang.org/post/uhgzgmowqcczczrdt...@forum.dlang.org

That PR may be useful for motivating this DIP.

Mike


It looks like all you need is a way to toggle attributes with a 
flag, like pure(isPure) or something.  IIRC, last time that came 
up, it turned into a bikeshedding fest about the syntax.  (I 
don't think parentheses works with UDAs.)  Anyway, yeah, we need 
the functionality.


However, this DIP is *way* more complicated.  I stand by what I 
said before: 
https://forum.dlang.org/post/dnmcqwkdfmommiiug...@forum.dlang.org 
 Jonathan M Davis said it in long form: 
https://forum.dlang.org/post/mailman.5429.1501206646.31550.digitalmar...@puremagic.com

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Mike Franklin via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on August 10 (3:59 AM GMT August 11), or when I make a post 
declaring it complete.


I don't know what's happening with this DIP, but I've recently 
encountered a real-world problem for which there is no palatable 
workaround that this DIP would likely solve:


https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123

My attempts to workaround the issue I posted at
https://forum.dlang.org/post/uhgzgmowqcczczrdt...@forum.dlang.org

That PR may be useful for motivating this DIP.

Mike

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Monday, 31 July 2017 at 19:27:46 UTC, Jesse Phillips wrote:

On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
* Remove the whole program defaults, I'm ok with it being 
changed in a re-implementation of the runtime (like the 
embedded example), we just don't need the extra confusion 
within user code.


The program defaults are there to make @safe by default a 
thing, and betterC by default a thing, which are covered in 
the _three Primary points_ of the semesters Vision 
document[1]. These would not normally be set (i.e. opt in).


I read that as more, Improve Druntime and phobos's us of @safe 
so that it becomes more usable.


Improving druntime and phobos is obviously important, but so is 
the ability for the end user to use it. If its hard to use less 
people will use it, conversely the easier it is the more likely 
people are to use it. Not that this also provides an easy way to 
find out which function are not @safe and fix them, without 
slapping @safe on main, i.e. build unit (package/library) at a 
time.


* Specifying inferred needs to be within druntime only, and 
thus may not need to exist.


I think there is usefulness in having it, particularly as the 
meta-default (defaultAttributeSet). Walter has ben pushing for 
some time to infer attributes by default. This would provide a 
directive for the compiler to do so. Please elaborate.


I don't expect inference to happen outside templates. Besides 
if the compiler infers the appropriate attributes by default, 
isn't 1. a default attribute redundant and 2. specifying 
inference redundant as the compiler defaults to inferring?


It happens already for dip1000 IIRC and I be surprised if, 
particularly for @safe, Walter didn't want more inference. 
Especially for minimal user effort.


The compiler will default functions to the first value of the 
enum [for my example].


( That would provide a pessimistic default and debates the 
ability for the compiler to infer)


Yes, just throwing in an example structure and why I mentioned 
[for my example]. But as said earlier infer and default are at 
odds.


I disagree. Even if infer wasn't the default I would certainly 
like to be able to have them be inferred at the flick of a 
compiler switch. It goes back to the ease of use argument, its 
more effort for me to manually annotate things.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Jesse Phillips via Digitalmars-d]

On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
* Remove the whole program defaults, I'm ok with it being 
changed in a re-implementation of the runtime (like the 
embedded example), we just don't need the extra confusion 
within user code.


The program defaults are there to make @safe by default a 
thing, and betterC by default a thing, which are covered in the 
_three Primary points_ of the semesters Vision document[1]. 
These would not normally be set (i.e. opt in).


I read that as more, Improve Druntime and phobos's us of @safe so 
that it becomes more usable.


* Specifying inferred needs to be within druntime only, and 
thus may not need to exist.


I think there is usefulness in having it, particularly as the 
meta-default (defaultAttributeSet). Walter has ben pushing for 
some time to infer attributes by default. This would provide a 
directive for the compiler to do so. Please elaborate.


I don't expect inference to happen outside templates. Besides if 
the compiler infers the appropriate attributes by default, isn't 
1. a default attribute redundant and 2. specifying inference 
redundant as the compiler defaults to inferring?


* I'm concerned user defined attributes could define a 
"defaults" for functions.


you mean user UDAs (if not please explain)? the default 
application of UDA is for core attributes only.


Yes I'm User's UDA (user defined attributes). I expected it 
wouldn't apply outside the context of core.attributes.



The compiler will default functions to the first value of the 
enum [for my example].


( That would provide a pessimistic default and debates the 
ability for the compiler to infer)


Yes, just throwing in an example structure and why I mentioned 
[for my example]. But as said earlier infer and default are at 
odds.



[So on and so forth]


Thanks for your suggestions.

[1]: https://wiki.dlang.org/Vision/2017H2

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
Thanks in advance to all who participate.

Destroy!


My primary points

* Don't formally deprecate the keywords, there is not enough 
justification to ever remove them.


Indeed the only reason for removing them would be to remove code 
from the compiler. They do no harm at all.


* Remove the whole program defaults, I'm ok with it being 
changed in a re-implementation of the runtime (like the 
embedded example), we just don't need the extra confusion 
within user code.


The program defaults are there to make @safe by default a thing, 
and betterC by default a thing, which are covered in the _three 
Primary points_ of the semesters Vision document[1]. These would 
not normally be set (i.e. opt in).


* Specifying inferred needs to be within druntime only, and 
thus may not need to exist.


I think there is usefulness in having it, particularly as the 
meta-default (defaultAttributeSet). Walter has ben pushing for 
some time to infer attributes by default. This would provide a 
directive for the compiler to do so. Please elaborate.


* I'm concerned user defined attributes could define a 
"defaults" for functions.


you mean user UDAs (if not please explain)? the default 
application of UDA is for core attributes only.




I think the updated document needs some additional rework, here 
are some examples:


# Rational

A number of issues with the existing functional attribute 
system have come up through the years.


* Certain attributes don't have a name, e.g. All functions 
''throws'' but this is not an existing attribute.
* The default attributes were not correctly chosen, e.g. all 
class methods should be ''final'' unless specified otherwise, 
and because of the first point declaring 'final:' at the top of 
the class cannot be undone.
* AliasSeq is provided to manage Attributes, but it doesn't 
handle built in attributes (I could be wrong but is what I'm 
getting from the document even though it isn't explicitly 
stated)

* ...

# Description

Function existing attributes and their unnamed counterpart will 
exist as an enum within core.attributes. This module will be 
implicitly imported to provide the symbols without explicit 
import or breaking existing code. The compiler will recognize 
the non-@ based attributes as the corresponding core.attribute.


...

## Implementation Details

--
module core.attribute;

enum Protection {
system,
safe,
trusted,
}

alias safe = Protection.safe;
...
---

The compiler will default functions to the first value of the 
enum [for my example].


( That would provide a pessimistic default and debates the 
ability for the compiler to infer)


[So on and so forth]


Thanks for your suggestions.

[1]: https://wiki.dlang.org/Vision/2017H2

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Jesse Phillips via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
Thanks in advance to all who participate.

Destroy!


My primary points

* Don't formally deprecate the keywords, there is not enough 
justification to ever remove them.
* Remove the whole program defaults, I'm ok with it being changed 
in a re-implementation of the runtime (like the embedded 
example), we just don't need the extra confusion within user code.
* Specifying inferred needs to be within druntime only, and thus 
may not need to exist.
* I'm concerned user defined attributes could define a "defaults" 
for functions.


I think the updated document needs some additional rework, here 
are some examples:


# Rational

A number of issues with the existing functional attribute system 
have come up through the years.


* Certain attributes don't have a name, e.g. All functions 
''throws'' but this is not an existing attribute.
* The default attributes were not correctly chosen, e.g. all 
class methods should be ''final'' unless specified otherwise, and 
because of the first point declaring 'final:' at the top of the 
class cannot be undone.
* AliasSeq is provided to manage Attributes, but it doesn't 
handle built in attributes (I could be wrong but is what I'm 
getting from the document even though it isn't explicitly stated)

* ...

# Description

Function existing attributes and their unnamed counterpart will 
exist as an enum within core.attributes. This module will be 
implicitly imported to provide the symbols without explicit 
import or breaking existing code. The compiler will recognize the 
non-@ based attributes as the corresponding core.attribute.


...

## Implementation Details

--
module core.attribute;

enum Protection {
system,
safe,
trusted,
}

alias safe = Protection.safe;
...
---

The compiler will default functions to the first value of the 
enum [for my example].


[So on and so forth]

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 11:45:21 UTC, Nick Treleaven wrote:

On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
Should public have @ on it? Should static have @ on it? What 
about scope, const, or shared?


If they are storage classes, they shouldn't have @. If they are 
statement or expression keywords, they shouldn't have @. Things 
like that are introduced with leading underscores: __traits, 
__gshared.


public etc could be @ attributes, but I see no reason to change 
them. This inconsistency can be explained by just saying 
visibility is special. (That said I wouldn't complain if they 
were changed too). Common keywords in other languages can help 
justify keeping those keywords in D.


the only catch there is that the `package` visibility takes an 
optional module following it and therefore can't be done as an 
enum.


it looks like the DIP is talking about what the default 
attributes in general are. It's one thing to slap a default 
set of attributes at the top of a module and then negate them 
later in the module


This is one part of the DIP I like - `@safe module foo;`. AIUI 
this would enable a @safe default that doesn't stop code such 
as templates being inferred as @system. This is not currently 
possible in D. I know Walter has talked about inferring 
attributes for all function bodies - in that case the DIP seems 
a bit less useful, but could still set the default for 
unittests, module ctors/dtors and main().


Hmm, after some discussions in this thread I decided that it 
would be better to have a "last applied wins" rule so as not to 
need the whole tag the module decl to set the default for the 
module. I suppose it could be bought back if need be but it's 
kind of redundant with "last applied wins". Templates may still 
be a bit of a problem.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nick Treleaven via Digitalmars-d]

On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
Should public have @ on it? Should static have @ on it? What 
about scope, const, or shared?


If they are storage classes, they shouldn't have @. If they are 
statement or expression keywords, they shouldn't have @. Things 
like that are introduced with leading underscores: __traits, 
__gshared.


public etc could be @ attributes, but I see no reason to change 
them. This inconsistency can be explained by just saying 
visibility is special. (That said I wouldn't complain if they 
were changed too). Common keywords in other languages can help 
justify keeping those keywords in D.


it looks like the DIP is talking about what the default 
attributes in general are. It's one thing to slap a default set 
of attributes at the top of a module and then negate them later 
in the module


This is one part of the DIP I like - `@safe module foo;`. AIUI 
this would enable a @safe default that doesn't stop code such as 
templates being inferred as @system. This is not currently 
possible in D. I know Walter has talked about inferring 
attributes for all function bodies - in that case the DIP seems a 
bit less useful, but could still set the default for unittests, 
module ctors/dtors and main().

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Olivier FAURE via Digitalmars-d]

On Friday, 28 July 2017 at 01:30:28 UTC, sarn wrote:
To be totally honest, as it stands it feels like architecture 
astronautics:

https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/


Yeah, I think you nailed it. This DIP does seem to come from a 
'what is the smartest, most elegant system I can design' logic; I 
don't see much value in it as something that would solve problems.


That's not to say that the rationale should be explained better, 
or the examples should be different, or this or that paragraph 
should be tweaked. I think this proposal is fundamentally flawed 
for the reasons Jonathan M Davis outlined.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[vit via Digitalmars-d]

On Friday, 28 July 2017 at 07:50:43 UTC, Daniel N wrote:

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP 
should occur in this thread. The review period will end at 
11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I 
make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it 
will be queued for the formal review and evaluation by the 
language authors.


Thanks in advance to all who participate.

Destroy!


I was hoping an attribute overhaul would go in a different 
direction.

1) Remove all negation
2) Add an true/false yes/no parameter etc.

@gc!no:
  ...
@gc!yes:
  ...


Or:


//Create symbol to attribute (new kind of symbol)
__attribute Pure = pure;

alias PureIf(bool X : true) = Pure;
alias PureIf(bool X : false) = AliasSeq!();


//expand UDA PureIf to pure if IsPure == true
void test(bool IsPure)()@PureIf!IsPure{
}

//can be in std.attrib or similar module:
__attribute Safe = @safe;
__attribute Nothrow = nothrow;

alias As = AliasSeq!(Pure, Nothrow, Safe);

//expand to pure nothrow @safe
void test2()@As{

}

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Daniel N via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on August 10 (3:59 AM GMT August 11), or when I make a post 
declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it will 
be queued for the formal review and evaluation by the language 
authors.


Thanks in advance to all who participate.

Destroy!


I was hoping an attribute overhaul would go in a different 
direction.

1) Remove all negation
2) Add an true/false yes/no parameter etc.

@gc!no:
  ...
@gc!yes:
  ...

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 06:31:08 UTC, Johannes Pfau wrote:

Am Thu, 27 Jul 2017 23:38:33 +
schrieb Nicholas Wilson :


It is actually a very simple change, from the end user
perspective.
* Function attributes that were keyword like, become regular
attributes.
* They can be applied to modules, acting as a default for
applicable symbols in the module.



I think it also makes sense from a compiler perspective. When 
these attributes were introduce, we didn't have UDAs yet. Then 
we introduced UDAs and now UDAs are more full-featured than the 
original compiler hardcoded attributes:


Indeed all the LDC compiler specific attribute are regular UDAs. 
This also open the way for more parametric attributes and reduces 
the "urgh more attributes" and since they would be symbols we can 
phase the _in_ with `@future`.


UDAs do not introduce names into the global namespace, UDAs can 
use fully qualified names, multiple UDAs can be combined or 
aliased (as commonly done in C for dll export attributes using 
#defines. We can't do such things in D right now). So I think 
moving the compiler attributes to UDAs is certainly useful.


But it seems this DIP fails to stress the rationale and 
confuses people with some implementation detail. I think it's 
important to show the simple use cases, where object.d auto 
imports everything and aliases are used so you can use normal 
@nogc void foo()... syntax. Then maybe show how to group or 
alias attributes.


-- Johannes


Duly noted.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Johannes Pfau via Digitalmars-d]

Am Thu, 27 Jul 2017 23:38:33 +
schrieb Nicholas Wilson :

> On Thursday, 27 July 2017 at 15:48:04 UTC, Olivier FAURE wrote:
> > On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:  
> >> DIP 1012 is titled "Attributes".
> >>
> >> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md  
> >
> > This DIP proposes a very complex change (treating attributes as 
> > Enums), but doesn't really provide a rationale for these 
> > changes.  
> 
> It is actually a very simple change, from the end user 
> perspective.
> * Function attributes that were keyword like, become regular 
> attributes.
> * They can be applied to modules, acting as a default for 
> applicable symbols in the module.
> 

I think it also makes sense from a compiler perspective. When these
attributes were introduce, we didn't have UDAs yet. Then we introduced
UDAs and now UDAs are more full-featured than the original compiler
hardcoded attributes:

UDAs do not introduce names into the global namespace, UDAs can use
fully qualified names, multiple UDAs can be combined or aliased (as
commonly done in C for dll export attributes using #defines. We can't
do such things in D right now). So I think moving the compiler
attributes to UDAs is certainly useful.

But it seems this DIP fails to stress the rationale and confuses people
with some implementation detail. I think it's important to show the
simple use cases, where object.d auto imports everything and aliases
are used so you can use normal @nogc void foo()... syntax. Then maybe
show how to group or alias attributes.

-- Johannes

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
On Friday, July 28, 2017 01:13:10 Nicholas Wilson via 
Digitalmars-d wrote:
IIRC the reason they lack a leading @ is purely historical and 
considered not good but not worth breaking code over. I 
believe this DIP presents an opportunity and reason to make 
that change. Existing code will still work i.e. we can 
deprecate the old form, since both the new and the old are 
implementation controlled, and make it become a positional 
keyword or the like.


The only reason that _any_ of them have @ on them was to avoid 
creating a new keyword. And I for one would hate to see @ on 
all of them.


Fair enough, but its always slightly annoyed me that `pure` and 
`nothrow` don't have leading '@'s.


It's just trading on inconsistency for another. Should public 
have @ on it? Should static have @ on it? What about scope, 
const, or shared? You're just taking a subset of the attributes 
and turning them into enums with @ on them and leaving some of 
them as-is.


This DIP is in the process of being amended to explicitly exclude 
linkage, storage class & visibility attributes. That Subset are 
function attributes under the 'Encompassed' and 'Optionally 
encompassed' subsections of "Attributes & attribute-like compiler 
behaviour encompassed in this DIP".



How is that making things more
consistent? It's just shuffling the attributes around and for 
some reason turns some of them into enums while leaving others 
as they are.


Its turning keyword-like compiler magic attributes into regular 
compiler attributes.


IMHO, doing anything to change the current attributes had 
better have an _extremely_ good reason, and this DIP does not 
give that. Yes, being able to negate attributes would be 
valuable, but that really doesn't seem to be what this DIP is 
about much as that's what it gives as a rationale. Instead, it 
seems to be talking about altering attributes in a manner which 
makes them way more complicated than they are now.


I also _really_ don't like the idea of having aliases for 
built-in attributes.


That is a feature.

If we had that, instead of looking at a function and seeing 
@safe, pure, nothrow, etc., we could end up seing something 
like @VibeDefault, and then you'd have to go figure out what on 
earth that was, and even after you figured out what it was, it 
could change later. At least with what we have now, I can know 
what I'm looking at.


I dont mean to be snide but either
1) ignore them, i see AliasSeq of attributes more useful for end 
users, i.e. application developers, or

2) use an IDE.



In addition, it looks like the DIP is talking about what the 
default attributes in general are. It's one thing to slap a 
default set of attributes at the top of a module and then 
negate them later in the module (which we can already do with 
attributes like public or @safe but can't do with some of the 
others like pure or nothrow). It's a different thing entirely 
to basically change the default attributes via a compiler 
switch. That's just dividing the language. You end up with code 
that works with one set of compiler switches but not another 
and is thus incompatible with other code - because of a 
compiler switch. Walter has been against such compiler flags 
every time that they've come up, and I am in complete 
agreement. We've only used them as transitional flags that are 
supposed to go away eventually (like -dip25 or -dip1000). 
Whether the code is legal or not should not depend on the 
compiler flags.


And honestly, showing stuff like 
@core.attribute.GarbageCollectedness.gc in the DIP makes it 
look _really_ bad.


That was an Illustrative mistake and I regret the confusion it 
has caused. I should have used `@gc` with `@gc` being an alias 
for @core.attribute.GarbageCollectedness.gc.


Sure, it might make sense from the standpoint of extensibility, 
but it's ridiculously long. We already arguably have too much 
of an attribute mess on your average non-templated function 
signature without stuff like that.


This dip is intended to reduce the amount of attribute spam by 
enabling defaults.


IMHO, if what we're trying to do is to be able to negate 
attributes, then we should looking at doing something like 
@nogc(false) or some other syntax that is about negation of an 
existing attribute.


The DIP is more than that, the benefit of being regular 
attributes (manipulation) and the ability to have configurable 
defaults,


This DIP is going off on a huge tangent from that with no 
justification as to why it would be worth the extra 
complication or the breakage that it would cause.


This would cause _very_ little if any, non-deprecatable breakage.

And it looks like a _lot_ of extra complication in comparison 
to what we have now.


The keyword-like attributes become regular attributes. I fail to 
see how that makes them any more complicated, IMO it makes them 
_less_ complicated (I am revising the DIP to remove the module 

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Jonathan M Davis via Digitalmars-d]

On Friday, July 28, 2017 01:13:10 Nicholas Wilson via Digitalmars-d wrote:
> IIRC the reason they lack a leading @ is purely historical and
> considered not good but not worth breaking code over. I believe
> this DIP presents an opportunity and reason to make that change.
> Existing code will still work i.e. we can deprecate the old form,
> since both the new and the old are implementation controlled, and
> make it become a positional keyword or the like.

The only reason that _any_ of them have @ on them was to avoid creating a
new keyword. And I for one would hate to see @ on all of them. It's just
trading on inconsistency for another. Should public have @ on it? Should
static have @ on it? What about scope, const, or shared? You're just taking
a subset of the attributes and turning them into enums with @ on them and
leaving some of them as-is. How is that making things more consistent? It's
just shuffling the attributes around and for some reason turns some of them
into enums while leaving others as they are.

IMHO, doing anything to change the current attributes had better have an
_extremely_ good reason, and this DIP does not give that. Yes, being able to
negate attributes would be valuable, but that really doesn't seem to be what
this DIP is about much as that's what it gives as a rationale. Instead, it
seems to be talking about altering attributes in a manner which makes them
way more complicated than they are now.

I also _really_ don't like the idea of having aliases for built-in
attributes. If we had that, instead of looking at a function and seeing
@safe, pure, nothrow, etc., we could end up seing something like
@VibeDefault, and then you'd have to go figure out what on earth that was,
and even after you figured out what it was, it could change later. At least
with what we have now, I can know what I'm looking at.

In addition, it looks like the DIP is talking about what the default
attributes in general are. It's one thing to slap a default set of
attributes at the top of a module and then negate them later in the module
(which we can already do with attributes like public or @safe but can't do
with some of the others like pure or nothrow). It's a different thing
entirely to basically change the default attributes via a compiler switch.
That's just dividing the language. You end up with code that works with one
set of compiler switches but not another and is thus incompatible with other
code - because of a compiler switch. Walter has been against such compiler
flags every time that they've come up, and I am in complete agreement. We've
only used them as transitional flags that are supposed to go away eventually
(like -dip25 or -dip1000). Whether the code is legal or not should not
depend on the compiler flags.

And honestly, showing stuff like @core.attribute.GarbageCollectedness.gc in
the DIP makes it look _really_ bad. Sure, it might make sense from the
standpoint of extensibility, but it's ridiculously long. We already arguably
have too much of an attribute mess on your average non-templated function
signature without stuff like that.

IMHO, if what we're trying to do is to be able to negate attributes, then we
should looking at doing something like @nogc(false) or some other syntax
that is about negation of an existing attribute. This DIP is going off on a
huge tangent from that with no justification as to why it would be worth the
extra complication or the breakage that it would cause. And it looks like a
_lot_ of extra complication in comparison to what we have now.

- Jonathan M Davis

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Mike via Digitalmars-d]

On Friday, 28 July 2017 at 01:26:19 UTC, Mike wrote:

On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote:


Terminology:
I was confused by the term "attribute group". Although the 
term is defined in the DIP, it implies a combination of 
attributes rather than a mutually exclusive attribute 
category.  Still having trouble understanding the DIP in 
detail due to this.


If you have a better name, please do tell.


Yeah, naming is hard.  I suggest "attribute class".


Or "attribute category", maybe if the word "class" causes too 
much ambiguity.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 01:26:19 UTC, Mike wrote:

On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote:


Terminology:
I was confused by the term "attribute group". Although the 
term is defined in the DIP, it implies a combination of 
attributes rather than a mutually exclusive attribute 
category.  Still having trouble understanding the DIP in 
detail due to this.


If you have a better name, please do tell.


Yeah, naming is hard.  I suggest "attribute class".


I like it.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[sarn via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


Like others in this thread have said, it needs more rationale.  
The rationale only mentions one actual problem: attributes can't 
be undone (which is a really important problem, by the way).  But 
in the abstract it says


[This DIP] does not (yet) propose any mechanism to disable 
compiler attributes directly (e.g. @!nogc).


Instead of coming up with more problems to solve, it then dives 
into describing an entire framework for doing *things* with 
attributes.  To be totally honest, as it stands it feels like 
architecture astronautics:

https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Mike via Digitalmars-d]

On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote:


Terminology:
I was confused by the term "attribute group". Although the 
term is defined in the DIP, it implies a combination of 
attributes rather than a mutually exclusive attribute 
category.  Still having trouble understanding the DIP in 
detail due to this.


If you have a better name, please do tell.


Yeah, naming is hard.  I suggest "attribute class".

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 00:32:33 UTC, Mike wrote:

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


Terminology:
I was confused by the term "attribute group". Although the term 
is defined in the DIP, it implies a combination of attributes 
rather than a mutually exclusive attribute category.  Still 
having trouble understanding the DIP in detail due to this.


If you have a better name, please do tell.



Rationale:
The rationale is weak, but reading the "Description" appears 
that there's more to this DIP than what the rationale 
describes.  I suggest an enumerated list of problem/solution 
pairs that this DIP addresses.


Good idea.


Description:
It is also possible for the end user to directly control 
core.attribute.defaultAttributeSet by editing DRuntime 
directly.


Does this mean we can create an @safe-by-default or 
@final-by-default runtime?  if so, cool!, but that should be 
spelled out in more detail in the rationale.


Hmm, the runtime may have to be a special case for attribute 
inference,
I suspect that it does a whole bunch of things that are unsafe 
and the GC itself being @nogc is a bit weird (though I suppose 
you just link it out anyway). Not to mention global state being 
impure.



@core.attribute.GarbageCollectedness.inferred
That is way too verbose.  Is that just an illustration or is 
that really what we would need to be typing out?




Illustration, I expect that one will be able to go

@infer!(GarbageCollectedness, FunctionSafety)
or
@infer!(nogc,safe)

to both mean the same thing (or a combination of the above), but 
infer will be the default anyway I suspect. where `infer` just 
selects the inferred value of the enum and build an AliasSeq from 
them



Breaking changes / deprecation process:
It would be nice to get some decision early from the leadership 
if they would be willing to deprecate the no-leading-@ on 
attributes that are used with such proliferation in D code, as 
otherwise there will be a lot of time reviewing and debating 
this for nothing.  Sounds like a risky gamble.


Mike


IIRC the reason they lack a leading @ is purely historical and 
considered not good but not worth breaking code over. I believe 
this DIP presents an opportunity and reason to make that change. 
Existing code will still work i.e. we can deprecate the old form, 
since both the new and the old are implementation controlled, and 
make it become a positional keyword or the like.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Mike via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


Terminology:
I was confused by the term "attribute group". Although the term 
is defined in the DIP, it implies a combination of attributes 
rather than a mutually exclusive attribute category.  Still 
having trouble understanding the DIP in detail due to this.


Rationale:
The rationale is weak, but reading the "Description" appears that 
there's more to this DIP than what the rationale describes.  I 
suggest an enumerated list of problem/solution pairs that this 
DIP addresses.


Description:
It is also possible for the end user to directly control 
core.attribute.defaultAttributeSet by editing DRuntime directly.


Does this mean we can create an @safe-by-default or 
@final-by-default runtime?  if so, cool!, but that should be 
spelled out in more detail in the rationale.



@core.attribute.GarbageCollectedness.inferred
That is way too verbose.  Is that just an illustration or is that 
really what we would need to be typing out?


Breaking changes / deprecation process:
It would be nice to get some decision early from the leadership 
if they would be willing to deprecate the no-leading-@ on 
attributes that are used with such proliferation in D code, as 
otherwise there will be a lot of time reviewing and debating this 
for nothing.  Sounds like a risky gamble.


Mike

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 July 2017 at 00:20:25 UTC, jmh530 wrote:
On Thursday, 27 July 2017 at 23:27:53 UTC, Nicholas Wilson 
wrote:



Might be useful to mention why not included.


This DIP focuses on function (i.e. @-like attributes), the 
rest of those attributes are storage classes/visibility 
classes or parametric in a way that doesn't fit with this DIP 
(extern(C++, A.B), package(foo) align(N).


So then you might make that more clear, such as by re-titling 
it "Function Attributes" instead of "Attributes" and change 
language in certain locations, like in the abstract, to refer 
to function attributions specifically instead of all attributes.


Thats a good idea.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[jmh530 via Digitalmars-d]

On Thursday, 27 July 2017 at 23:27:53 UTC, Nicholas Wilson wrote:



Might be useful to mention why not included.


This DIP focuses on function (i.e. @-like attributes), the rest 
of those attributes are storage classes/visibility classes or 
parametric in a way that doesn't fit with this DIP (extern(C++, 
A.B), package(foo) align(N).


So then you might make that more clear, such as by re-titling it 
"Function Attributes" instead of "Attributes" and change language 
in certain locations, like in the abstract, to refer to function 
attributions specifically instead of all attributes.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 July 2017 at 18:06:41 UTC, jmh530 wrote:
I think those are only for overwriting @nogc module, but the 
DIP should be more clear on this matter. I would assume you can 
import core.attribute to simplify that.


core.attribute will be implicitly imported. That is the FQN. As a 
regular attribute it can be aliased.


Also, the DIP doesn't provide names for the attribute groups 
for the other ones. I assume GarbageCollectedness is just named 
that for the purpose of the example and is something that could 
be changed. Ideally, it would provide the names for each of the 
different groups as part of the DIP.


Heh, I know how much fun bike shedding is on the D forums...

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 July 2017 at 16:56:14 UTC, ketmar wrote:

Mike Parker wrote:


DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP 
should occur in this thread. The review period will end at 
11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I 
make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it 
will be queued for the formal review and evaluation by the 
language authors.


Thanks in advance to all who participate.

Destroy!


didn't get the rationale of the DIP at all. the only important 
case -- attribute cancelation -- is either missing, or so 
well-hidden that i didn't found it (except fast mention). 
everything other looks like atronautical complexity for the 
sake of having some "abstract good" (that is, for all my years 
of using D as the only lanugage i'm writing code into, i never 
had any need to "group defaults" or something -- only to 
selectively cancel attrs).


tl;dr: ketmar absolutely didn't got what this DIP is about.


Hmm, maybe a "last applied wins" could work, although this may 
require some complex changes to the compiler if the order that 
attributes apply is unspecified.


As in reply to a sibling comment the change is very simple: 
keyword- like function attributes instead become regular 
attributes.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 July 2017 at 17:35:34 UTC, Adrian Matoga wrote:
I don't want to see monsters like 
"@core.attribute.GarbageCollectedness.inferred" as part of any 
declaration, ever.
I agree that the problem is valid, but I don't think adding the 
complexity and verboseness presented in the DIP can solve it.


You almost certainly won't, although 
"@core.attribute.GarbageCollectedness.inferred" would still be 
valid. GarbageCollectedness.inferred is a regular attribute and 
can be aliased to whatever you want, put in an AliasSeq or hidden 
behind some template that generates a whole bunch of attributes.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 July 2017 at 15:48:04 UTC, Olivier FAURE wrote:

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


This DIP proposes a very complex change (treating attributes as 
Enums), but doesn't really provide a rationale for these 
changes.


It is actually a very simple change, from the end user 
perspective.
* Function attributes that were keyword like, become regular 
attributes.
* They can be applied to modules, acting as a default for 
applicable symbols in the module.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 July 2017 at 15:40:01 UTC, jmh530 wrote:

On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote:



_Why_ it works like that I have no idea.



I thought that the attributes were just using the same behavior 
as public/private/etc.


Anyway, isn't that the same type of behavior this DIP is 
suggesting? There is an @nogc module foo; example in the DIP 
that has a gc function included and doesn't say anything about 
it being an error.


The DIP has a list of attributes not encompassed, but there are 
missing attributes from [1]. For instance, the visibility 
attributes are not encompassed, but that is not mentioned. In 
this case, they are grouped and have a default (public) and an 
opposite (private). However, it would break a lot of code to 
force them to use @. Might be useful to mention why not 
included.


https://dlang.org/spec/attribute.html


Hmm. With  private/package/protected/public/export you can mix 
and match them as you please:


public:

void foo() {}
void bar() {}
private:
void baz() {}
int a,b;
public int c;

whereas if it were to be encompassed by this DIP that would no 
longer work. Maybe it should work, perhaps a last attribute wins 
(assuming previous `@attributes:` come before it in the list)?



Might be useful to mention why not included.


This DIP focuses on function (i.e. @-like attributes), the rest 
of those attributes are storage classes/visibility classes or 
parametric in a way that doesn't fit with this DIP (extern(C++, 
A.B), package(foo) align(N).

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote:
"at the top of a file means that one can never "undo" those 
attributes"


That's not true for `@safe`. This is perfectly legal:

@safe:

void foo()  { ... }// foo is @safe
void bar() @system { } // bar is @system


_Why_ it works like that I have no idea.

Atila


Huh.  I guess it's because there are three values in that group, 
unlike the rest of them, and the compiler handles them 
differently.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Iakh via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

Destroy!


Extend rationale: could be application to templates and using 
with CTFE.


"inferred" is not consistent. As I understand inferred applies to 
templates only. And default value is so called 
inferred_or_system. So it is inferred for templates and system 
for everything else. So whole safety group is:

 - safe
 - system
 - trusted
 - inferred_or_safe / soft_safe
 - inferred_or_system / soft_system

Re: DIP 1012--Attributes--Preliminary Review Round 1

[rjframe via Digitalmars-d]

On Thu, 27 Jul 2017 14:44:23 +, Mike Parker wrote:

> DIP 1012 is titled "Attributes".
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


1. I would like to see consistency; I'd rather see @nogc and @gc than @nogc 
and @core.attributes.[whatever].gc, so all these attributes should be 
aliased alike.

2. I don't really understand the need for this. The two times I wanted a 
whole module @safe but failed (so note I'm speaking from a lack of 
experience), I just placed the one or two functions above the attribute.

Though mixing combinations of attributes on functions would be greatly 
simplified by this proposal, I personally don't know how common that is, 
so I don't know the value in the proposal.

3. I don't like @inferred. If I'm going to call a function, I need to know 
whether I can call it from a @safe/@nogc/@whatever function. I can't 
imagine trying to work with Phobos (or any other library) if it documented 
@inferred everywhere. Unless I've missed the point.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[jmh530 via Digitalmars-d]

On Thursday, 27 July 2017 at 17:35:34 UTC, Adrian Matoga wrote:


I don't want to see monsters like 
"@core.attribute.GarbageCollectedness.inferred" as part of any 
declaration, ever.
I agree that the problem is valid, but I don't think adding the 
complexity and verboseness presented in the DIP can solve it.


I think those are only for overwriting @nogc module, but the DIP 
should be more clear on this matter. I would assume you can 
import core.attribute to simplify that.


Also, the DIP doesn't provide names for the attribute groups for 
the other ones. I assume GarbageCollectedness is just named that 
for the purpose of the example and is something that could be 
changed. Ideally, it would provide the names for each of the 
different groups as part of the DIP.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Adrian Matoga via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on August 10 (3:59 AM GMT August 11), or when I make a post 
declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it will 
be queued for the formal review and evaluation by the language 
authors.


Thanks in advance to all who participate.

Destroy!


I don't want to see monsters like 
"@core.attribute.GarbageCollectedness.inferred" as part of any 
declaration, ever.
I agree that the problem is valid, but I don't think adding the 
complexity and verboseness presented in the DIP can solve it.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[ketmar via Digitalmars-d]

Mike Parker wrote:


DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP should occur in 
this thread. The review period will end at 11:59 PM ET on August 10 (3:59 
AM GMT August 11), or when I make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, the DIP 
will be scheduled for another round. Otherwise, it will be queued for the 
formal review and evaluation by the language authors.


Thanks in advance to all who participate.

Destroy!


didn't get the rationale of the DIP at all. the only important case -- 
attribute cancelation -- is either missing, or so well-hidden that i didn't 
found it (except fast mention). everything other looks like atronautical 
complexity for the sake of having some "abstract good" (that is, for all my 
years of using D as the only lanugage i'm writing code into, i never had 
any need to "group defaults" or something -- only to selectively cancel attrs).


tl;dr: ketmar absolutely didn't got what this DIP is about.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Olivier FAURE via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md


This DIP proposes a very complex change (treating attributes as 
Enums), but doesn't really provide a rationale for these changes.


The DIP's written rationale is fairly short, and only mentions 
"We need a way to conveniently change default values for 
attributes" which I feel doesn't really justifies these complex 
new semantics.

Re: DIP 1012--Attributes--Preliminary Review Round 1

[jmh530 via Digitalmars-d]

On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote:



_Why_ it works like that I have no idea.



I thought that the attributes were just using the same behavior 
as public/private/etc.


Anyway, isn't that the same type of behavior this DIP is 
suggesting? There is an @nogc module foo; example in the DIP that 
has a gc function included and doesn't say anything about it 
being an error.


The DIP has a list of attributes not encompassed, but there are 
missing attributes from [1]. For instance, the visibility 
attributes are not encompassed, but that is not mentioned. In 
this case, they are grouped and have a default (public) and an 
opposite (private). However, it would break a lot of code to 
force them to use @. Might be useful to mention why not included.


https://dlang.org/spec/attribute.html

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Atila Neves via Digitalmars-d]

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:

DIP 1012 is titled "Attributes".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on August 10 (3:59 AM GMT August 11), or when I make a post 
declaring it complete.


At the end of Round 1, if further review is deemed necessary, 
the DIP will be scheduled for another round. Otherwise, it will 
be queued for the formal review and evaluation by the language 
authors.


Thanks in advance to all who participate.

Destroy!


"at the top of a file means that one can never "undo" those 
attributes"


That's not true for `@safe`. This is perfectly legal:

@safe:

void foo()  { ... }// foo is @safe
void bar() @system { } // bar is @system


_Why_ it works like that I have no idea.

Atila