This seems like a problem worth solving — or rather worth making the solution
public, since this is already in use as an undocumented feature!
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?
The proposal touches on this in the “Effect on API resilience” section:
> Any changes to the body of a declaration annotated as @inlinable should be
> considered very carefully. As a general guideline, we feel that @inlinable
> makes the most sense with "obviously correct" algorithms which manipulate
> other data types abstractly through protocols, so that any future changes to
> an @inlinable declaration are optimizations that do not change observed
> behavior.
>
> Also, an @inlinable function implementation must be prepared to interact with
> multiple versions of the same function linked into a single binary. For
> example, if a hashing function is @inlinable, the hash algorithm must not be
> changed to avoid introducing inconsistency.
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.
The potential for undetected bugs seems enormous. I wonder if there’s a need
for extra assistance for library authors, e.g.:
• A tool that allows one to take binaries for multiple versions of a lib with
inlinables, and repeatedly runs a test suite using a randomly selected version
of each inlinable func every time it’s used
• Static sanity checks (but what would they be?)
• Strict module version match conditions on @inlineable (but then dependency
hell takes up residence in the compiler?)
• Bail on compilation and JIT everything (ha)
Or is this not as dangerous as I’m imagining it to be?
Cheers, P
> On Dec 20, 2017, at 6:19 PM, 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?
>
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
