<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Dec 28, 2015, at 2:04 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Dec 28, 2015, at 1:39 PM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a>> wrote:<br class=""><br class="">I'm not sure I understand the use case. Aren't these optimizations that could be better handled by the compiler? Do we really want to provide hints like these manually in our own libraries? Instead of `value: Int? = nil`, why not `value: Int = 42`?<br class=""></blockquote><br class="">I agree that part of this is simply an optimization. The part that was interesting enough that I thought it is worth sharing is that it could improve resilience in a way that a default value does not allow.<br class=""><br class="">That said, it is not a “proposal”. I’m not sure whether it is really worth considering or not. But I think it is interesting enough to toss out to the community and see what the response is.<br class=""></div></div></blockquote></div><br class=""><div class="">You can provide resilience with a non-optional parameter by making the default argument the result of calling a resilient function (or evaluating a resilient property):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">@availability(x.y)</div><div class="">internal func defaultForFoo() -> Int { return 941 }</div><div class=""><br class=""></div><div class="">public func foo(value: Int = defaultForFoo()) { }</div></blockquote><div class=""><br></div></blockquote><div><br></div>I don't think I've tried calling a lower visibility function to get a default like that before. That's interesting. Good to know it is possible.<br><br><div>I was especially thinking about the ability to add or remove option parameters without breaking ABI. In that case the existing function might be able to forward to a new overload with a different set of parameters with defaults, but it also seems like that would lead to ambiguity at call sites in many cases when compiling against the new binary.</div><div><br></div><div>Will there be a way to "hide" the old function (i.e. give it in some kind of "public for backwards compatibility only" visibility) so call sites are still unambiguous during compilation and the module interface is not unnecessarily cluttered while also retaining the original function for ABI compatibility? (I hope that long sentence is comprehensible)</div><div><br></div><div>If it is possible to effectively add and remove parameters with default values one way or another without breaking ABI then the option parameter idea is almost certainly not worth the complexity.</div></body></html>