@safe(bool)

[Guillaume Boucher via Digitalmars-d]

On Saturday, 19 August 2017 at 16:02:27 UTC, bitwise wrote:
> We have to consider the potential for abuse.

I don't like measuring features on the potential for abuse, but 
this feature cries for abuse.  Even in the simpler form of your 
proposal.

Let's say there are two functions with conditional @safe

f(T)(...) @safe(!hasAliasing!T) {...}
g(bool B)(...) @safe(B) {...}

and we combine them into another function,

h(T,bool B) @safe(!hasAliasing!T && B) {
   f(T)(...);
   g(B)(...);
}

then in the correct @safe specification there is an additional 
clause for every conditionally-safe function.

This doesn't scale well.

So the guideline would be to use your feature very rarely and 
only if it's obvious from the meaning of the template arguments; 
if it gets too complicated, just don't specify it.

Which would mean the feature should only be used in few corner 
cases, and is thus not worth the cost of complicating the 
language.


You already commented on the other usage of dip 1012, the @nice 
and @naughty attributes.  They just don't scale in a similar way.


C++ has had the same feature for some time: noexcept(true) means 
noexcept, noexcept(false) means an exception may be thrown (of 
course this works with any constant expressions).
I just grepped through Boost and I have found 53 uses of 
noexcept(expression), from 5264 total uses of noexcept (excluding 
the math library). And Boost is one of those libraries that are 
overly precise with such things to a degree that the code becomes 
unreadable.  In code outside of Boost and the standard library, 
noexcept(expression) it is basically unused.