> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Furthermore, the old code needs to continue working without source changes,
> because updating to a new SDK must not break existing code. (It can introduce
> new warnings, but even that is something that should be considered carefully.)
>
> So: this proposal is designed to handle the use cases both for Swift library
> authors to come and for C APIs today, and in particular Apple's Objective-C
> SDKs and how they've evolved historically.
I will let your very comprehensive rationale brew a little bit more in my mind
and reread it, but I still think this is a bit leaning too much over to library
authors than library consumers (not unlike the closed by default discussion we
all had a while ago).
I remain very unconvinced by the “updating library/SDK” must be source
compatible. Especially if it is major version change and a deprecated method
has been removed, methods have changed signature, etc... Backward compatible
runtime with code compiled against the previous SDK yes, source compatible no.
I feel like this change will make the life easier for library authors, but
risks making it easier and easier to make mistakes in apps using the libraries:
exhaustive switching over enums is a good important feature that risks going
away (the default matters) for not a huge effective benefit to app developers.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
