[swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson]

> On Nov 28, 2017, at 3:28 PM, Slava Pestov <spestov at apple.com> wrote:
> 
> 
> 
>> On Nov 28, 2017, at 1:25 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> 
>>> On Nov 28, 2017, at 3:18 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Nov 28, 2017, at 8:44 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>>> 
>>>> func makeResource(
>>>>     with configuration: Configuration = () where Configuration == Void, 
>>>>     actionHandler: @escaping (Action) -> Void = { _ in } where Action == Never
>>>> )
>>> 
>>> Similar question to the one I posed earlier — what happens if I’m using makeResource() from a generic context? Is the conditional default argument simply not available?
>> 
>> Right.  If the constraints are not met at the call site the default is not available.  I think you understood, but looking at the example above I omitted the resource type parameter.  It should read:
>> 
>> func makeResource<R: Resource>(
>>     with configuration: R.Configuration = () where R.Configuration == Void, 
>>     actionHandler: @escaping (R.Action) -> Void = { _ in } where R.Action == Never
>> )
>> 
>>> 
>>> In this case, how is it different from defining some static overloads of makeResource(), some of which have default arguments and some of which are generic?
>> 
>> From the point of view of the call site it is not different.  The differences are that:
>> 
>> * the user is presented with a single API rather than several overloads
> 
> Is this less confusing than encountering a new ‘where’ clause on default arguments, which is probably rare enough that many users will spend months/years using Swift without seeing it?

I think so.  The where clause is used for constraints consistently in the language so the meaning of seeing one attached to a default argument should be intuitive for anyone familiar with the generics system.  In the motivating use case I have there would still be an overload set available but it would be much smaller with this feature and therefore the available signatures would be much more clear.

> 
>> * the compiler doesn’t have to reason about an overload set which might improve build times, etc
> 
> They’re effectively equivalent, because we still have to decide which subset of the default arguments apply at a given call site by checking all combinations of constraints.

Interesting.  Are there no advantages to the compiler that would be possible if an overload set was replaced with constrained default arguments?

> 
> Slava
> 
>> 
>>> 
>>> Slava
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/91820716/attachment.html>