DIP 1029---Add throw as Function Attribute---Community Review Round 1

[Arine]

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.