[swift-evolution] Optimization attributes

Charles Kissinger crk at akkyra.com
Thu Jan 7 16:47:02 CST 2016

Yes! (As far as I’m concerned.) Operating on scopes was what I originally had in mind, but I then overlooked the # modifier approach.


> On Jan 7, 2016, at 2:10 PM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> Would these be more appropriate as scoped modifiers similar to #available(...)?
>     func foo() {
>         ...
>         #unchecked {
>             // stuff in here is unchecked
>         }
>     }
> On Thu, Jan 7, 2016 at 1:55 PM, Charles Kissinger via swift-evolution <swift-evolution at swift.org <mailto: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?
> -CK
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/a6479f8c/attachment.html>

More information about the swift-evolution mailing list