[Accepted] SE-0496: `@inline(always)` Attribute

Evolution Announcements
1

Hello, Swift community!

The review of SE-0496: @inline(always) Attribute ended on October 16th.

Feedback on this proposal was generally positive. There were some questions raised during the review about specific behaviors or design points, which are addressed below:

  • Should the current spelling @inline(__always) be deprecated or removed? There are no plans to make any changes to the current spelling (and given its underscore-prefixed spelling, it should not be considered officially supported). @inline(always) is not a drop-in replacement because it provides stronger guarantees than the __always version.

  • Should there be a syntax to permit inlining of specific call sites rather than whole functions? The Language Steering Group does agree that this would be useful, but is a future direction that is separable from this proposal.

  • Should there be an explicit syntax required to acknowledge usage of an @inline(always) function in one of the situations where it will neither be inlined nor diagnosed? While this would be consistent with the new attribute's goal of diagnosing when functions can definitively not be inlined, it would also make it a source-breaking change to add @inline(always) to any function. Unlike similar examples like unsafe, we do not consider this to be the correct trade-off.

  • Should @inlineable functions be able to invoke @inline(always) functions of any visibility? Allowing this would raise at least two concerns:

    • This would violate module import visibility rules; for example, an (file)private function using declarations from a (file)private imported module would need to have those imports exposed if the function was inlined into another module.
    • (file)private declarations include the containing source file's name as part of their symbol mangling. It would be an ABI-breaking change to rename a source file in a library if a (file)private function that referenced another (file)private symbol was inlined into another module.

    The proposal as written avoids these issues by its intersection with @inlineable (implying it for public/open/package functions and allowing it for internal functions), and that attribute already places the desired restrictions on what those functions are allowed to reference.

Therefore, the Language Steering Group believes that the attribute as proposed is a positive improvement and we accept this proposal.

Thanks to everybody who participated in the review!

—Tony Allevato, review manager

8 Likes