Hi Paul,
Thanks for reviewing the proposal!
> On Dec 20, 2017, at 9:21 PM, Paul Cantrell <cantr...@pobox.com> wrote:
>
> A concern: how would a library author reason about, and check for bugs in,
> the combinatorial explosion of old and new implementations that could exist
> simultaneously with this feature in use?
I don’t have a simple answer to this unfortunately, other than the author being
really careful, perhaps keeping around build artifacts that were compiled
against older versions of the library and testing those.
> That last paragraph gives a relatively trivial example, but the implications
> are daunting! If I understand correctly, anything in a library that uses any
> @inlinable or @abiPublic code must be prepared to deal with every possible
> combination of every past published implementation of that code. And that
> “every possible combination” is not per function, but per…call site?
>
> Suppose we have this:
>
> // Module A
>
> @inlineable func bar() { ... }
>
> // Module B
>
> @inlineable func foo() {
> if whatever {
> bar(0) // compiler decides to inline this...
> } else {
> bar(1) // ...but not this, for whatever reason
> }
> }
>
> // Module C
>
> func baz() {
> foo()
> }
>
> …and suppose B was compiled against A v1.0 but C was compiled against A v2.0.
> Then, if I’m following, it’s possible for bar(0) to use the 1.0
> implementation but bar(1) to use the 2.0 impl. Do I have that right? It seems
> to be what the hash value example is getting at.
That is correct. Another example is if module A publishes an inlinable
function, and module B and C depend on A, but B and C were compiled with
different versions of A. Then a fourth module D that depends on B and C might
see two different published versions of this function.
> Or is this not as dangerous as I’m imagining it to be?
It *is* pretty dangerous, which is why I hope this feature is used judiciously
by third-party binary frameworks. With source frameworks that are built
together with an app and always recompiled, this is less of a concern.
Also we are using this feature extensively in the standard library, so as the
standard library evolves we will learn and develop best practices, hopefully
without too many hiccups :)
Slava
>
> Cheers, P
>
>
>> On Dec 20, 2017, at 6:19 PM, Ted Kremenek via swift-evolution
>> <swift-evolution@swift.org <mailto: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
>>
>> <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
>> <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
>>
>> <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?
>>
>> Is the problem being addressed significant enough to warrant a change to
>> Swift?
>>
>> Does this proposal fit well with the feel and direction of Swift?
>>
>> If you have used other languages or libraries with a similar feature, how do
>> you feel that this proposal compares to those?
>>
>> How much effort did you put into your review? A glance, a quick reading, or
>> an in-depth study?
>>
>> Thanks,
>> Ted Kremenek
>> Review Manager
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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
