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

[Arine]

On Tuesday, 5 May 2020 at 14:47:55 UTC, Petar Kirov [ZombineDev] 
wrote:
> On Tuesday, 5 May 2020 at 14:39:24 UTC, Petar Kirov 
> [ZombineDev] wrote:
>> On Tuesday, 5 May 2020 at 08:55:58 UTC, Walter Bright wrote:
>>> On 4/17/2020 6:03 AM, Tove wrote:
>>>> I like it, but would prefer:
>>>> throw!bool
>>>> 
>>>> 1) makes meta-programming easier
>>>> 2) would allow deprecating nothrow (in very long term)
>>>> 3) there is precedence in C++ 'noexcept(expression)'
>>>> (even if they made the wrong choice with using the negated 
>>>> specifier)
>>>> 
>>>> Any arguments against?
>>>
>>> throw!bool implies it is throwing a bool. Besides, with 
>>> throw/nothrow we already have the full functionality.
>>
>> Are you saying that the following will work:
>>
>>     mixin(doThrow? "throw" : "nothrow")
>>     void func(bool doThrow)()
>>     {
>>     }
>>
>> ?
>>
>> Otherwise, I'd say that the best solution, which I think 
>> Andrei agreed with [1] is `attribute(true)` and 
>> `attribute(false)` or more generally: `attribute(boolExpr)`.
>>
>> [1]: https://forum.dlang.org/post/mknspb$1dgl$1@digitalmars.com
>
> An alternative proposal would be to merge the built-in function 
> attributes `pure`, `nothrow`, `@nogc` and 
> `@safe`/`@trusted`/`@system` with compiler-recognized UDAs in 
> the language, like [2], as proposed by multiple people:
>
> - https://forum.dlang.org/post/lo2avr$2hgo$1@digitalmars.com
> - 
> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1012.md
>
> Honestly, I think this is the best way to go, and everything 
> else is a waste of time.
>
> [2]: 
> https://github.com/dlang/druntime/blob/master/src/core/attribute.d

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. I 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.