> On Dec 21, 2017, at 11:05 AM, Greg Titus via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
Yeah, the main downside I can think of with Chris’s approach is that for developers publishing source-only packages, version number ranges are probably overkill. I believe Jordan had a similar objection at some point in our internal discussions. However, treating @inlinable as shorthand for @available(inlinable) might be sufficient. > > And the Tony-style spelling of @abiPublic should _clearly_ be > “internal(external)” for its amazingly oxymoronic yet accurate spelling. If oxymoronic spelling discourages abuse of these features, I’m all for it ;-) Slava > > — Greg > >> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> 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 > > _______________________________________________ > 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
