Code that ends up running in a default case somewhere in one of the several 
places you switch over that enum that you forgot about... well, it may not 
break source code compatibility, but it may introduce subtle bugs... submarine 

Sent from my iPhone

> On 5 Jan 2018, at 08:11, Goffredo Marocchi via swift-evolution 
> <> wrote:
>> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution 
>> <> 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 mailing list

Reply via email to