I guess eg .binade and .ulp, and a lot of the initializers should have it. But why limit this improvement to the floating point types? I'd think most types in the std lib have many properties, methods and initializers, that should similarly be marked @effects(readnone).
I'm really looking forward to trying out a Swift version with @effects(readnone) added everywhere where it makes sense in the std lib.
The reason for my enthusiasm / eagerness
I'm a bit obsessed by this because almost every time I bump into and investigate significant differences in performance that are caused by seemingly irrelevant changes to source code, at least part of the explanation will be due to Swift's current inability to see and utilize the fact that some initializers, properties or methods have ...
... no side effects and no dependencies on the state of the program. They always return an identical result given identical inputs.
For example, I might have some heavily used function that has a loop of only a few (not billions) iterations, the number of which I expect to be definitely statically knowable, as in eg
for i in 0 ..< MemoryLayout<T>.size {
...
}
And I notice that this loop (including its contents) will get optimized to various degrees depending on seemingly irrelevant changes to the loop, its contents or its context.
An attempt at preventing off topic discussion
By "seemingly irrelevant", I mean that you cannot understand how they are relevant unless you:
-
Know unreasonably much about the implementation of (your current version of) Swift, including inconsistently marked and/or inefficiently implemented low-level operations in the std lib, shortcomings of the optimizer, etc.
-
Understand exactly how the above inconsistencies will interact in the context of your code.
This is of course true for all languages in a way, but the number of performance related inconsistencies and bugs that are likely to be at play in any given piece of Swift, is still so high that it makes it impossible to develop an intuition for performance, and the only way forward seems to be a lot of experiments and bug reports. And further improvements to the benchmark suite.
But perhaps the optimizer isn't taking any advantage of the @effects attribute yet?