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