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

[Arine]

I really don't like how small these DIPs are. It seems they don't 
have direction on their own.

This is given as part of the rationale:

     void bar(); // may throw

     struct S1 {
         nothrow void foo() { bar(); } // error, bar() throws
     }

     nothrow {
         struct S2 {
             void foo() { bar(); } // no error, as the nothrow 
block does not apply
         }
     }


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?

If you are going to add `throw` why aren't the rest of the 
attributes getting inverses? Pure? @nogc? etc...

> Although this DIP does not propose making exceptions opt-in, 
> the throw attribute is a key requirement for it.

It seems this DIP's sole purpose is as a stepping stone for the 
next DIP to change the default of nothrow to be the default. On 
its' own it doesn't make sense, if your are trying to fix the 
disparity of being able to turn off attributes there's no reason 
to not include the rest of the attributes as well.

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. If the intention is the fix the problem 
that attributes don't have inverses to be able to turn them 
on/off, then I don't see why you need a separate DIP for each and 
every attribute. Include them all in the same DIP as well as 
address the strange behavior with structs/classes that was 
included as part of the rationale.

If this is really just a stepping-stone DIP, what if the next DIP 
is rejected, but this one is accepted? What purpose would it have 
served? Just adding `throw` isn't a significant/meaningful enough 
change on it's own, if you look solely at this DIP.