[swift-evolution] [Pitch] Option parameters (potential resilience advantages)

[Matthew Johnson]

Sent from my iPhone

> On Dec 28, 2015, at 2:52 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Dec 28, 2015, at 12:29 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Dec 28, 2015, at 2:04 PM, Joe Groff <jgroff at apple.com> wrote:
>>> 
>>> 
>>>>> On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 
>>>>> On Dec 28, 2015, at 1:39 PM, Stephen Celis <stephen.celis at gmail.com> wrote:
>>>>> 
>>>>> 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`?
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> 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):
>>> 
>>> @availability(x.y)
>>> internal func defaultForFoo() -> Int { return 941 }
>>> 
>>> public func foo(value: Int = defaultForFoo()) { }
>> 
>> 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.
>> 
>> 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.
>> 
>> 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)
> 
> 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. 
> 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151228/7e9d3677/attachment.html>