Sent from my iPhone
> On Dec 28, 2015, at 2:52 PM, Joe Groff <[email protected]> wrote:
>
>
>> On Dec 28, 2015, at 12:29 PM, Matthew Johnson <[email protected]> wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Dec 28, 2015, at 2:04 PM, Joe Groff <[email protected]> wrote:
>>>
>>>
>>>>> On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>> On Dec 28, 2015, at 1:39 PM, Stephen Celis <[email protected]>
>>>>> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
