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 future. > 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. Slava
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
