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)
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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
