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
3 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.
3 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)
This proposal is now up for active review in here.
Please note that the proposal now under review only discusses @inline(always). The variant that would have subsumed @_alwaysEmitIntoClient (suggested above as @inline(only)) has been removed from this proposal since there is another discussion about @_alwaysEmitIntoClient semantics being discussed in this thread.
2 Likes