Hi Johannes,

Thanks for reviewing this proposal!

> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
> <swift-evolution@swift.org> wrote:

> The library I'm working on will presumably never have stable ABI as you'd 
> naturally build it with your application. However we also don't want to miss 
> on the cross-module optimisation & specialisation and I suspect there are 
> quite a few (mostly open-source) libraries in the same space. I'm pretty sure 
> everybody would just end up littering their code with @abiPublic/@inlinable 
> (or the @available(...) syntax Chris Lattner proposed) without actually 
> meaning that.
> Summing up: I think this feature is crucial but shouldn't come without a 
> compiler "where all declarations become implicitly @inlinable, and all 
> private and internal declarations become @abiPublic". I really don't want to 
> litter the code with attributes that aren't what I mean. (basically `swift 
> build --global-resilience-domain`) Having this compiler mode also makes these 
> attributes IMHO really niche and therefore I can only sympathise with's 
> Chris' sentiment to not litter the global attribute namespace.

I agree that a ‘completely non-resilient’ compiler mode would be great when 
building libraries that are always shipped together, and I hope Swift gains 
such a feature one day, possibly built on top of the very infrastructure used 
to implement this proposal!

However, the goal of this proposal is to formalize some language features that 
already exist and are used by the standard library. Clearly making everything 
fragile is a non-starter for the standard library in an ABI-stable world.

I do hope that this attribute is not abused in the manner in which you 
describe, but I’m not sure the potential for abuse is reason enough to not run 
the proposal — people are already using the underscored attribute today, 
risking source breakage and bugs due to insufficient test coverage in the 

> C(++) as described in the proposal and Haskell 
> (https://wiki.haskell.org/Inlining_and_Specialisation 
> <https://wiki.haskell.org/Inlining_and_Specialisation>), where {-# INLINABLE 
> myFunction #-} (quoting the docs) causes exactly two things to happens.
>       • The function's (exact) definition is included in the interface file 
> for the module.
>       • The function will be specialised at use sites -- even across modules.
> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
> function than any other.

Note that Swift’s compiler is the same — @inlinable does not influence 
optimizer decisions to inline or not.

Also currently the proposal is implemented by binary serialization of the SIL 
IR, but nothing in it precludes serializing inlinable function bodies as source 
code in the future — in fact we are likely to go in that direction if we 
implement the proposed textual ‘stable’ module format.


swift-evolution mailing list

Reply via email to