[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Jordan Rose]

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 <swift at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180105/3f39064e/attachment.html>