On 16.01.20 13:51, Adam D. Ruppe wrote:
> On Thursday, 16 January 2020 at 08:47:01 UTC, Timon Gehr wrote:
>> Also, alarmingly, 'pure' the same issue even though it appears in that expression:
> 
> Since lambdas are inferred, the attr: should not apply to them anyway. That's my proposal - exempt anything that is inferred from the attr: things (you can still attach attributes directly to it to force the issue).
> 
> There's no reason to force the issue with these; attr: is to kinda change the default and inference already is a more generally useful default.
> 

Yes, I fully support that.

On Thursday, 16 January 2020 at 08:04:35 UTC, Walter Bright wrote:
> On 1/15/2020 7:26 AM, Arine wrote:
>> I'm completely blown away, you don't even know that @safe passes through to the next scope?
>
> My mistake. What actually happens is here:
>
>     sc2.stc &= STC.safeGroup;
>
>     https://github.com/dlang/dmd/blob/master/src/dmd/aggregate.d#L136
>
> where the storage class passed from the outer scope to the struct/class scope is zeroed out except for @safe/@trusted/@system.
>
> So @safe "flows through" to the struct scope, while nothrow, pure, @nogc, etc., do not.

So when you were proposing @system: as a solution to the change to default of @safe, you thought you had to add @system to the top of every struct, and that's the solution you promoting as a best practice?

Honestly I'd prefer rebuttal about my point regarding defaults. If the defaults aren't what you want them to be, the language forces you to pollute your code with `attributes:` because they don't flow into the next scope. If that's the only reason, and there's no other reason why it behaves this way. It'd be best to change it so that the user the option to choose what is best for them. If they feel it is best add it to every scope, that's their option to. But right now it's forced onto us.

On Thursday, 16 January 2020 at 20:19:24 UTC, Arine wrote:
> On Thursday, 16 January 2020 at 08:04:35 UTC, Walter Bright wrote:
>> On 1/15/2020 7:26 AM, Arine wrote:
>>> I'm completely blown away, you don't even know that @safe passes through to the next scope?
>>
>> My mistake. What actually happens is here:
>>
>>     sc2.stc &= STC.safeGroup;
>>
>>     https://github.com/dlang/dmd/blob/master/src/dmd/aggregate.d#L136
>>
>> where the storage class passed from the outer scope to the struct/class scope is zeroed out except for @safe/@trusted/@system.
>>
>> So @safe "flows through" to the struct scope, while nothrow, pure, @nogc, etc., do not.
>
> So when you were proposing @system: as a solution to the change to default of @safe, you thought you had to add @system to the top of every struct, and that's the solution you promoting as a best practice?
>
> Honestly I'd prefer rebuttal about my point regarding defaults. If the defaults aren't what you want them to be, the language forces you to pollute your code with `attributes:` because they don't flow into the next scope. If that's the only reason, and there's no other reason why it behaves this way. It'd be best to change it so that the user the option to choose what is best for them. If they feel it is best add it to every scope, that's their option to. But right now it's forced onto us.

(I am in the @safe and throw camp as default.)

I really like Adam's ideas about the attributes: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_13.html
That way we can easily get code, how we like to, without much pollution (i would not consider one line in a module a pollution), no matter what the defaults are.

This DIP is just a little step, which might or might not go in any direction afterwards.

On Tuesday, 14 January 2020 at 10:44:17 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1029, "Add throw as Function Attribute":
>
> https://github.com/dlang/DIPs/blob/8c48c98a0495f73db9a2d5c4aef502b9febe9673/DIPs/DIP1029.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 January 28, 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 of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.
>
> #DIP1029
> #throw

Impossible without cleaning a bit the attributes before. instead of adding a new keyword we should make all the function attributes '@' attributes, and deprecate 'nothrow' as a keyword and encourage @nothrow instead.

This DIP encourages the bizarre situation where function attributes can be '@' attribs or keywords.

On Wednesday, 22 January 2020 at 22:47:51 UTC, user1234 wrote:
> On Tuesday, 14 January 2020 at 10:44:17 UTC, Mike Parker wrote:
>> [...]
>
> Impossible without cleaning a bit the attributes before. instead of adding a new keyword we should make all the function attributes '@' attributes, and deprecate 'nothrow' as a keyword and encourage @nothrow instead.
>
> This DIP encourages the bizarre situation where function attributes can be '@' attribs or keywords.

in my opinion something like

    void foo() @safe @nogc pure nothrow {}

should become

    void foo() @safe @nogc @pure @nothrow {}

so "throw" as a function attribute is just a big no.
This will create a debt in case attribs syntax got normalized one day.

On Tuesday, January 14, 2020 3:44:17 AM MST Mike Parker via Digitalmars-d wrote:
> This is the feedback thread for the first round of Community Review for DIP 1029, "Add throw as Function Attribute":
>
> https://github.com/dlang/DIPs/blob/8c48c98a0495f73db9a2d5c4aef502b9febe967 3/DIPs/DIP1029.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 January 28, 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 of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.
>
> #DIP1029
> #throw

I do think that we should consider adding something like pure(true) and pure(false) - and possibly something like pure(default) or pure(inferred) - for attributes where that makes sense, because it would work better with metaprogramming (at least if an expression can be provided instead of only boolean literals). And if we went with something like that, arguably it doesn't make sense to add throw in addition to nothrow, since throw could just be nothrow(false). However, the double negative is arguably undesirable, and even if a boolean solution would be desirable, this DIP is an improvement over the current sitution and does not make it so that we can't add a more flexible solution for negating function attributes in general later.

- Jonathan M Davis

On Thursday, 23 January 2020 at 05:06:21 UTC, Jonathan M Davis wrote:
> I do think that we should consider adding something like pure(true) and pure(false) - and possibly something like pure(default) or pure(inferred) - for attributes where that makes sense, because it would work better with metaprogramming (at least if an expression can be provided instead of only boolean literals). And if we went with something like that, arguably it doesn't make sense to add throw in addition to nothrow, since throw could just be nothrow(false). However, the double negative is arguably undesirable, and even if a boolean solution would be desirable, this DIP is an improvement over the current sitution and does not make it so that we can't add a more flexible solution for negating function attributes in general later.
>
> - Jonathan M Davis

I constantly need to turn on/off @safe and @nothrow based on version(WebAssembly).
so i'm all for adding a simple way to toggle attributes.
my proposal would be something like this:

```
struct pure {
private:
 enum P {
  Yes,No,Default,Inferred,
 }
 W _pure;
 this(P p) { _pure = p; }
public:
 this(bool b = true) { _pure = b ? P.Yes : P.No; }
 enum default = pure(P.Default);
 enum inferred = pure(P.Inferred);
}

alias impure(bool b = true) = pure!(!b);
```

so we can have:

```
@pure
@impure
@pure!false
@impure!false
@pure.default
@pure.inferred
@impure.default
@impure.inferred
```

On Tuesday, 14 January 2020 at 10:44:17 UTC, Mike Parker wrote:

> 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 January 28, or when I make a post declaring it complete.
>
>

This review round has finished. Please save further feedback for the next review round.

On 1/14/2020 1:22 PM, Dennis wrote:
> On Tuesday, 14 January 2020 at 10:44:17 UTC, Mike Parker wrote:
>> #DIP1029
>> #throw
> 
> First of all thanks for adding the section with a grammar diff and adding it to FunctionAttribute. I forgot to mention during draft review it should probably be added to StorageClass as well:
> https://dlang.org/spec/grammar.html#StorageClass
> 
> Otherwise it can't appear in an AutoFunctionDeclaration unlike nothrow.
> ```
> void main() {
>      nothrow foo() {} // currently allowed
>      throw foo() {} // not allowed after this DIP because `throw` is no `StorageClass`
> }
> ```
> 
> However, adding it to StorageClass adds an ambiguity:
> 
> ```
> void foo()() {
>      nothrow bar(); // allowed according to grammar spec
>      throw bar(); // throw statement or function declaration?
> }
> ```

I'm pretty sure the parser can take care of that with lookahead.

On Friday, 7 February 2020 at 08:56:06 UTC, Walter Bright wrote:
>> ```
>> void foo()() {
>>      nothrow bar(); // allowed according to grammar spec
>>      throw bar(); // throw statement or function declaration?
>> }
>> ```
>
> I'm pretty sure the parser can take care of that with lookahead.

But which one is it?
I think declarations usually have priority (e.g. `A * b;` is always a declaration with pointer type instead of multiplication) but arguably parsing it as a throw statement makes more sense here.