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@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
