[swift-evolution] Optimization attributes

[Joe Groff]

> On Jan 7, 2016, at 1:55 PM, Charles Kissinger via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I wanted to float the idea of adding new attributes for function and method declarations that would allow various safety checks to be turned off (or on) at the level of individual functions. Examples of such attributes would be:
> 
> @uncheckedmath  // integer overflow
> @uncheckedbounds  // array bounds
> @unchecked      // no safety checks, equivalent to -Ounchecked
> @fastmath         // if the —fastmath compiler option becomes available in the future
> 
> These attributes could have an argument with a value of true or false, allowing the global compiler option to be overridden for particular functions.
> 
> This is primarily motivated by the fact that the -Ounchecked compiler option is a very blunt instrument. It globally disables several unrelated safety checks such as integer overflow and array bounds checking. And it operates only at the level of an entire compilation unit. It is hard to reason about all the effects of this option across a large module, and isolating specific code to be compiled separately with -Ounchecked is inconvenient.
> 
> These new attributes would allow specific safety checks to be enabled or disabled on a per-function basis. I think the overall effect would be safer programs, because developers would be less likely to resort to the global -Ounchecked compiler option when searching for better performance.
> 
> Are optimization attributes such as these feasible?

Scoped semantics changes like this are problematic. It's easy to accidentally change behavior you didn't intend to by applying the attributes too broadly, and it's harder for readers to understand the behavior within the contextual modifiers. It's also hard to define exactly what these mean, since many of the operations in question are defined as library functions. I think it's better in general to use explicitly unsafe operations, for instance, using &+ instead of + to ignore overflow checks. You could theoretically get something like the scoped attribute effect by using scoped imports, which could bring in a different set of operations shadowing the standard ones:

do {
  import FastMath // FastMath.* now shadows Swift.*

  return 4*x*x + 2*x + 1
}

-Joe