[swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Greg Titus]

I come from a perspective similar to Johannes, in that: for my work we are interested in the performance improvements of cross-module optimization and specialization but we regularly rebuild frameworks along with apps and explicitly don’t need ABI versioning. Unlike him, I’m not that concerned with littering attributes for inlinability around, but for our purposes the original proposed spelling of @inlinable/@abiPublic or even better, Tony’s proposed public(inlinable) makes for easier understanding when reading the code than Chris’s proposed @available() extensions, which semantically leans much more heavily on the ABI versioning concept that we won’t otherwise need.

And the Tony-style spelling of @abiPublic should _clearly_ be “internal(external)” for its amazingly oxymoronic yet accurate spelling.

	— Greg

> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>> Reviews are an important part of the Swift evolution process. All review feedback should be sent to the swift-evolution mailing list at:
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review manager. 
>> 
>> When replying, please try to keep the proposal link at the top of the message:
>> 
>> Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>> ...
>> Reply text
>> ...
>> Other replies
>> What goes into a review of a proposal?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. 
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> 	• What is your evaluation of the proposal?
> 
> I'm working on a performance sensitive library and we're sometimes bitten quite hard by not being able to cross-module inline & specialise. Therefore, it's thrilling to see that you're working in this area.
> 
> However, I have to admit that I believe this language feature will most likely be grossly abused. 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.
> 
> 
>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
> 
> see above.
> 
> 
>> 	• Does this proposal fit well with the feel and direction of Swift?
> 
> to back up the 'swift' claim, cross-module inlining & specialisation is absolutely necessary. However this should also be achievable with a 'I don't need a stable ABI for this product' mode in the compiler :).
> 
> 
>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> C(++) as described in the proposal and Haskell (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.
> 
> 
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> read the proposal (and believe to understand it).
> 
> -- Johannes
> 
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution