[swift-evolution] Enums and Source Compatibility

[Wallacy]

@Slava

If my understanding is correct. If I compile my application with the x.y.z
version of a Apple System Framework (like Cocoa). And this framework is
updated, several calls from my application to the "new" framework version
x.z.a behave like in the x.y.z version for compatibility issues right? I
see this being mentioned in the Cocoa documentations sometimes.

Is possible to do this here?

I usually don't care about non-exhaustive enums. We avoid this even in
languages which do not enforce us (using external tools sometimes). But i
can understand the "need" in some projects.


Em sáb, 30 de set de 2017 às 21:00, Slava Pestov via swift-evolution <
swift-evolution at swift.org> escreveu:

> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I don’t see how it’s impractical. Quite a lot about how the library should
> be optimally compiled and used depends on what you plan to do with it. If
> it’s going to be installed somewhere private and you can guarantee clients
> will always have the latest version, you can assume all data types are
> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An
> example of that would be a library embedded inside an iOS app bundle. If
> it’s going to be installed somewhere public and expose some API (like
> Apple’s frameworks), then you’re going to have to think about binary
> compatibility.
>
> That also means that in-app libraries are optimised as much as they can
> be, and that resilience-related changes on the declaration side can be
> limited to the limited set of Swift developers who truly have to care about
> that.
>
>
> We do plan on exposing an -enable-resilience flag which basically does
> what you describe. When a library is built without -enable-resilience, all
> types are assumed to be fixed layout, etc. However, we don’t want language
> flags to change language semantics, so exhaustive/nonexhaustive still make
> sense even when building without resilience, I think. When you switch over
> a non-exhaustive enum that came from a library built without
> -enable-resilience, the compiler can still use the most efficient possible
> access pattern and assume that no new cases will be introduced, but the
> type checker would still require a default case to be present. The
> optimizer can then basically strip out the default case as dead code.
>
> Slava
>
>
> - Karl
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171002/940bbd62/attachment.html>