On 1/14/2020 3:53 AM, IGotD- wrote:
> Correct me if I'm wrong, what I've understood in the text is that making "nothrow" the default is also a goal which is not covered in this DIP but perhaps in a future DIP.

That is the plan. It has no flesh at the moment.

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?
}
```

Now it should be noted that dmd doesn't actually parse that. I opened an issue for that:

https://issues.dlang.org/show_bug.cgi?id=20504

That could make the problem away in this case, but I think the DIP should consider possible ambiguities like that that might be introduced.

Further feedback:

- I still think that other attributes should be considered for this DIP. As I mentioned during draft review:

> pure isn't fortunate enough to have an opposite keyword for it. If we end up going with e.g. pure(false) or !pure, then you'll end up with either inconsistently not allowing nothrow(false) or !nothrow, or multiple ways to specify a throw function.

It would be annoying to users if soon after the introduction of `throw` as a function attribute it would be phased out because a new consistent mechanism is introduced for all function attributes.

On the other hand, adding an option to negate the nothrow attribute in the short term is welcome, and it can still be kept around with little harm even if it gets superceded.

- I still think it should be stated how the new attribute interacts with __traits(getFunctionAttributes):
```
void t0() nothrow; // tuple("nothrow", "@system")
void t1() throw; // tuple("throw", "@system")
void t2(); // tuple("@system") or tuple("throw", "@system")?
```

On Tuesday, 14 January 2020 at 20:35:44 UTC, Walter Bright wrote:
> [snip]
>
> Because it's the way the other attributes work. Trying to change this would be very disruptive. The reason it works this way is it is unkind to the purpose of scoping. If the attributes passed into nested scopes, then you'll pretty much force a coding guideline to "list all the attributes needed at the beginning of each scope" so it won't silently break when someone adds a:
>
>  attribute:
>
> at the top.
>
> [snip]

I agree that it is disruptive, but I would hang my hat on the argument not being germane because such a change would affect other attributes as well. Keeping the change small is good, IMO.

Nevertheless, I think a case could be made for changing the behavior. However, I would limit the change to
attribute:
while keeping the behavior of
attribute { code }
unchanged.

I would phrase this as attribute: being for scope-wide defaults (including nested), while attribute { code } would be for scope-level defaults only. That makes these two features a bit more orthogonal, though potentially at a cost of some disruption.

However, attribute: can currently be replaced by an attribute { code } wherever it is used. That means that if you change attribute: to pass into nested scopes, while leaving attribute { code } unchanged, then any code that could be broken by the change could be easily fixed by using attribute { code }. It becomes a lot more disruptive if you change attribute { code } too.

On 1/14/2020 8:44 AM, Dukc wrote:
> This would be a step forward, of course. But would not it be better to kill the one-way attribute problem in one go -meaning, making an antiattribute for `pure` and `@nogc` too?

Because for the anti-nothrow we already have a trivial solution staring us in the face, we just have to pick it up. I have no explanation for not seeing the obvious before.


> In addition, I suggest that there should be a way to use [`pure:`/`nothrow:`/`@nogc:`/`@safe:`/their antiattributes] so that they only apply when attributes are not inferred - not for templated functions. This would also remove a big obstacle from front of DIP1028, as one could just mark the whole module `@system` with one statement without killing template `@safe` or `@live` inference.

It turns out that there's another "attribute" under the covers - the default. Only when an attribute is the default does inference come into play. Hence, when "nothrow" becomes the default, there will be actually three states - throw, nothrow, and default.

It works out rather nicely. It's in play for safe/trusted/system already, and has been since the beginning.

On Tuesday, 14 January 2020 at 22:30:40 UTC, Walter Bright wrote:
> Hence, when "nothrow" becomes the default

IF, not when. I support this DIP as a nice independent move, but I am going to fight you on the step of changing the default.

But, my plan here:
http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_13.html#my-attribute-proposal---no-changes-to-defaults

to make `nothrow:` (etc) go into the child scopes except templates means we have a less disruptive way to make this work without formally changing the defaults.

On 14.01.20 18:24, Arine wrote:
> 
> It's not even solving a problem.

That's just plainly untrue. It solves the problem that if you put

nothrow:

There is no way to invert it for specific functions that you want to be able to throw. It's explained in the DIP.

On Tuesday, 14 January 2020 at 20:42:48 UTC, Walter Bright wrote:
> On 1/14/2020 7:18 AM, Arine wrote:
>> Otherwise this shouldn't be it's own DIP. If the intention is this is only required for another DIP, this should just be included in that DIP.
> It does make sense on its own.

It doesn't. Not with what's written in the DIP. If you don't care to elaborate I guess that's the end of that discussion.

> Furthermore, I don't want to distract the coming discussion on "nothrow as default" with all the debate about throw vs throws vs @throw, etc.

So talking about something that's part of the DIP is distracting from the DIP? Why are you trying to control the narrative that takes place in a DIP? You shouldn't be splitting up DIPs into non-nonsensical pieces just so you can tell people to not discuss certain aspects that relate to the current DIP because they are also part of another DIP.

> BTW, anyone wanting to discuss the merits of "nothrow as default" please use the "nothrow by default" thread started by Steven Schveighoffer on Jan 4.

I'd say as long as it mentions making nothrow the default in the DIP, this is fair to discuss here. It is part of this DIP after all.

On Tuesday, 14 January 2020 at 23:04:02 UTC, Adam D. Ruppe wrote:
> On Tuesday, 14 January 2020 at 22:30:40 UTC, Walter Bright wrote:
>> Hence, when "nothrow" becomes the default
>
> IF, not when. but I am going to fight you on the step of changing the default.

Same here.

> I support this DIP as a nice independent move,

It just needs @gc, and impure and i'd say it'd be good to go.

> But, my plan here:
> http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_13.html#my-attribute-proposal---no-changes-to-defaults
>
> to make `nothrow:` (etc) go into the child scopes except templates means we have a less disruptive way to make this work without formally changing the defaults.

This makes more sense than what we have right now for this DIP. Good work.

On 15.01.20 06:05, Arine wrote:
> On Wednesday, 15 January 2020 at 02:42:09 UTC, Timon Gehr wrote:
>> On 14.01.20 18:24, Arine wrote:
>>>
>>> It's not even solving a problem.
>>
>> That's just plainly untrue. It solves the problem that if you put
>>
>> nothrow:
>>
>> There is no way to invert it for specific functions that you want to be able to throw. It's explained in the DIP.
> 
> The first sentence

The remainder of your post was just more of the same bad logic. I can reformulate my answer to make more clear how it relates to your post: It's clearly solving a problem. The DIP illustrates a problem and solves a problem that exists. The problem is that `nothrow` does not have an inverse and it is a sufficient enough solution to that problem.

> of a comment in the middle of someone else's discussion

This is the Community Review for DIP 1029. If you don't want your comments criticized, please don't post them here. This is not the place to have private conversations. Thanks!

On Tuesday, 14 January 2020 at 20:35:44 UTC, Walter Bright wrote:
> On 1/14/2020 7:18 AM, Arine wrote:
>> Why isn't this being fixed so that `nothrow{}` then applies to `S2.foo()`? Why is it even part of the rationale if there's no intention to fix this?
>
> Because it's the way the other attributes work. Trying to change this would be very disruptive. The reason it works this way is it is unkind to the purpose of scoping. If the attributes passed into nested scopes, then you'll pretty much force a coding guideline to "list all the attributes needed at the beginning of each scope" so it won't silently break when someone adds a:
>
>  attribute:
>
> at the top.

You already have to do that if you don't want the defaults. It's not even optional, you're forced to do it for the very reason you are giving for why it is the way it is to avoid putting attributes at each new scope. Lol ironic.

It's not something that will be very silent either. As all the attributes for @nogc, pure, and nothrow will error when any other function tries to call those functions and those attributes have somehow been overwritten.

>> If you are going to add `throw` why aren't the rest of the attributes getting inverses? Pure? @nogc? etc...
>
> Since we already have a keyword available, it makes sense to use it. throw/nothrow nicely complement each other.

There's problems to using "throw", as others have mentioned. I agree with others that "throws" is better. It's not low hanging fruit you make it out to be.

>> Just adding `throw` isn't a significant/meaningful enough change on it's own, if you look solely at this DIP.
>
> It does add value on its own, as the user can now decide what his default is and override it as necessary. The value isn't huge, but the change is trivial, so the cost/benefit ratio is still good.

Great! Include `@gc` and `impure` in this DIP and I'm sold.