<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:52 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 12:29 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class="">Sent from my iPhone</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">On Dec 28, 2015, at 2:04 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><div class=""><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 class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><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 class=""></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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></blockquote><div><br class=""></div><div>Yeah, you ought to be able to do this by deprecating the old entry point and implementing it by forwarding to the new more general entry point. </div></div><div class=""><br></div></blockquote><br><div>Cool. The option parameter idea seems to have no value to us then. I suspected as much but wasn't sure so thought it was worth seeing what the response was. Thanks for taking time to respond.</div></body></html>