> On Nov 28, 2017, at 1:25 PM, Matthew Johnson <[email protected]> wrote:
> 
> 
>> On Nov 28, 2017, at 3:18 PM, Slava Pestov <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>>> On Nov 28, 2017, at 8:44 AM, Matthew Johnson <[email protected] 
>>> <mailto:[email protected]>> 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?

> * 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.

Slava

> 
>> 
>> Slava
> 

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to