[swift-evolution] [RFC] "Library Evolution Support in Swift ('Resilience')"

David Owens II david at owensd.io
Wed Feb 10 15:13:22 CST 2016


OK, I can be more correct: nondeterministic behavior. At least it will be consistent in the path that happens. =)


> On Feb 10, 2016, at 1:07 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> I do object to the word "undefined", which in the C family of languages means "the compiler can do anything it wants". In this case you will definitely get behavior equivalent to the old code, or equivalent to the new code, and the section on optimizing inlineable functions makes it clear that the inlineable code must not make assumptions about what library it's deployed against. Again, memory and type safety are preserved, while under "undefined behavior" in a C language they definitely would not be.
> 
> Jordan
> 
>> On Feb 10, 2016, at 13:00, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>> 
>> Actually, there are quite a few places that allow for the same type of behavior: @inlineable, accessors, enums, structs, etc...
>> 
>> As soon as I see these words: "existing clients may use the new implementations, or they may use the implementations from the time they were compiled, or a mix of both" or similar, we've ventured right back into undefined territory. 
>> 
>> That concerns me.
>> 
>> -David
>> 
>>> On Feb 10, 2016, at 12:45 PM, David Owens II via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Feb 8, 2016, at 6:24 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> This last point is a specific case of a general tenet of Swift: the default behavior is safe. Where possible, choices made when an entity is first published should not limit its evolution in the future.
>>> 
>>> 
>>> Regarding this:
>>> 
>>>> Changing or removing a default value is permitted but discouraged; it may break or change the meaning of existing source code.
>>> 
>>> 
>>> Maybe I'm being dense, but how is something with a caveat of "discouraged" and "it may break or change" in-line with "the default behavior is safe"? I've got no qualms with putting the default value in the client code; I actually think that is fine.
>>> 
>>> However, my concern is that you will have different behavior depending on if you simply drop in the updated binary vs recompile against the binary. Even worse if you have multiple components within your app that link against the library. If only one of those components is recompiled on release, you now have a problem of conflicting behavior within your own app because of the client-side calling the API will be using different values.
>>> 
>>> It would seem that removing the default value could be permitted (though maybe still discouraged) because this will result in a compiler error in the scenario above. It's still possible to have different behavior in your components, but now it's no longer implicitly happening. However, changing the default parameter seems highly problematic.
>>> 
>>> -David
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/96e7e465/attachment.html>


More information about the swift-evolution mailing list