Feedback Thread: DIP 1029--Add throw as Function Attribute--Final Review

[Petar]

On Tuesday, 5 May 2020 at 15:03:41 UTC, Arine wrote:
> On Tuesday, 5 May 2020 at 14:47:55 UTC, Petar Kirov 
> [ZombineDev] wrote:
>>  [..]
>>
>> - https://forum.dlang.org/post/lo2avr$2hgo$1@digitalmars.com
>> - 
>> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1012.md
>>

>
> That'd be worse I think. I don't want to have to look up what 
> @spiffy means, especially if you can start mixing them.

This problem is no different than the problem of finding good 
names for your functions, variables, or UDAs.

Additionally, since the set of all UDAs applied to a function is 
basically an AliasSeq, you have the same "problem" already:

     import std.meta : AliasSeq;

     struct Attr1 { string s; }
     struct Attr2 { bool b; }

     alias AllAttributes = AliasSeq!(Attr1("asd"), Attr2(true));

     void fun() @AllAttributes { }
     void hun() @Attr1("asd") @Attr2(true) { }

     static assert(
         __traits(getAttributes, fun) ==
         __traits(getAttributes, hun)
     );

Which version is better depends on the circumstances and taste :)

> prefer the idea of just having auto inferred functions, all of 
> them. That way you don't have to wait for a function in a 
> library to be properly tagged as @nogc when the author doesn't 
> tag it as such (even though it is). Basically the same problem 
> with @safe right now.

I agree that attribute inference is key. However it's not always 
possible, especially in the situation you describe, which is 
probably the one for which that's needed the most. The problem is 
that when the author of a function doesn't commit to the function 
attributes, he's free to change the implementation in a way that 
makes a function previously inferred as @nogc no longer @nogc, 
thereby breaking code that mistakenly relied on it being @nogc 
(ditto for the other attributes).