> On 21 Dec 2017, at 4:06 pm, 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.
forgot to mention GHC's -fspecialise-aggressively which is its way of saying,
just specialise things across modules even without '{-# INLINABLE ... #-}'
which is basically the compilation mode I'm asking for :).
>
>
>> • 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
