Clarifications here only! I don't think I have too much more to convince you;
at this point we've looked at the same landscape and come to different
conclusions. Although I think I'm more optimistic than you are about being able
to build a binary compatibility checker.
> On Jan 5, 2018, at 06:52, Swift <sw...@davedelong.com> wrote:
>
>> They can't tell themselves whether your app supports the new case, other
>> than the heavy-handed "check what SDK they compiled against" that ignores
>> the possibility of embedded binary frameworks.
>
> To be fair, a “linked on or after” check isn’t that heavy-handed. It’s a
> single if-statement. Yes, they become unwieldy if you’ve got them
> *everywhere* in your library code, which is why I brought up the point
> earlier that I’d really love to see more in the way of facilitating this sort
> of link-dependent behavior that apps are expecting.
Just to clear up this point, I meant "heavy-handed" in that it's just an
approximation of whether the client is actually ready to deal with new
complexity. It's not an unreasonable one, but it still forces clients to
potentially think about all the new things if they just want to update to use
one of them.
Maybe "coarse-grained" would have been better phrasing. That also covers the
"on or off for the entire app" aspect.
>>> Teaching the compiler/checker/whatever about the linking semantics of
>>> modules. For modules that are packaged inside the final built product,
>>> there is no need to deal with any unexpected cases, because we already have
>>> the exhaustiveness check appropriate for that scenario (regardless of
>>> whether the module is shipped as a binary or compiled from source). The app
>>> author decides when to update their dependencies, and updating those
>>> dependencies will produce new warnings/errors as the compiler notices new
>>> or deprecated cases. This is the current state of things and is completely
>>> orthogonal to the entire discussion.
>>
>> This keeps sneaking into discussions and I hope to have it formalized in a
>> proposal soon. On the library side, we do want to make a distinction between
>> "needs binary compatibility" and "does not need binary compatibility". Why?
>> Because we can get much better performance if we know a library is never
>> going to change. A class will not acquire new dynamic-dispatch members; a
>> stored property will not turn into a computed property; a struct will not
>> gain new stored properties. None of those things affect how client code is
>> written, but they do affect what happens at run-time.
>
> This is incorrect; binary compatibility absolutely affects how code is
> written. No swift library available today is written with binary
> compatibility in mind, because it’s a non-issue. If it were a pervasive
> issue, then you’d see a lot more diligence in libraries about not straight-up
> breaking things between releases.
>
> Other responses on this thread have mentioned removing implementations
> between releases, which is an excellent illustration of this point: when
> writing a binary-compatible library, *you cannot remove implementations*. So
> the very fact that people think that it’s ok to do so is an explicit
> refutation of the assertion that the manner in which client code is written
> is independent of the consideration of a library needing binary compatibility.
I very carefully said "client", and then Ted reminded me yesterday in another
context that that's not a standard term. So to be clear, I meant "none of these
performance-related things would change what an app can and can't do with the
API of the library", not anything broader about the design of the library or
even about the design of the app.
Jordan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
