<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2016, at 1:00 PM, David Owens II via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Actually, there are quite a few places that allow for the same type of behavior: @inlineable, accessors, enums, structs, etc...</div></div></blockquote><div><br class=""></div><div>Of these, inlineable functions definitely have the same problem, but I'm not sure what you're referring to with regard to accessors, enums, or structs. These will all be accessed by opaque interfaces (unless declared fixed-contents), so clients are guaranteed to use the framework implementation.</div><div><br class=""></div><div>-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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&nbsp;both" or similar, we've ventured right back into undefined territory.&nbsp;</div><div class=""><br class=""></div><div class="">That concerns me.</div><div class=""><br class=""></div><div class="">-David</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 10, 2016, at 12:45 PM, David Owens II via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 8, 2016, at 6:24 PM, Jordan Rose via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">This last point is a specific case of a general tenet of Swift:&nbsp;<b class="">the default behavior is safe</b>. Where possible, choices made when an&nbsp;entity is first published should not limit its evolution in the future.</blockquote></div></div></div></blockquote><br class=""></div><div class=""><br class=""></div><div class="">Regarding this:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Changing or removing a default value is permitted but discouraged; it may break or change the meaning of existing source code.</blockquote></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-David</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>