> 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

Reply via email to