Given that there are good reasons for non-@inline(always) functions to have no ABI (back-deployment, ability to make source-compatible ABI-breaking changes later), it feels like the best path forward is standardizing @_alwaysEmitIntoClient to support that use case. (My preferred spelling is @abi(none)) Then, it would be clear that these are entirely separate axes of configuration.
3 Likes
I agree with this. In the discussion of an embedded Swift linkage model, we also discussed needing the opposite of @_alwaysEmitIntoClient, which I'm calling @_neverEmitIntoClient: it means that a symbol will always be generated for the entity and its body will never be available for inlining, even when the compilation mode defaults to it (e.g., due to cross-module optimization or embedded Swift, for example).
[Edit: I've started a separate thread on formalizing @_alwaysEmitIntoClient independently of the @always(inline) proposal.]
Doug
2 Likes
Keep in mind also that @inlinable implies @usableFromInline if the decl is internal. So if someone annotates their internal function as @inline(always), then it will become part of the ABI, which is perhaps surprising.
2 Likes
This statement was meant to be qualified (and is in the current version of the proposal) by the annotation being public'ish (open, public, package)