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.
