> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution > <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
