> On Nov 28, 2017, at 3:28 PM, Slava Pestov <spes...@apple.com> wrote: > > > >> On Nov 28, 2017, at 1:25 PM, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >> >>> On Nov 28, 2017, at 3:18 PM, Slava Pestov <spes...@apple.com >>> <mailto:spes...@apple.com>> wrote: >>> >>> >>> >>>> On Nov 28, 2017, at 8:44 AM, Matthew Johnson <matt...@anandabits.com >>>> <mailto:matt...@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 >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
