It's kludgy, but we could have something like: ``` @defaultArgument(configuration = (), where R.Configuration == Void) @defaultArgument(actionHandler = { _ in }, where R.Action == Never) func makeResource(with configuration: R.Configuration, actionHandler: @escaping (R.Action) -> Void) -> R { ... } ```
I don't like that we'd be setting a default argument on something lexically before even encountering it in the declaration, but it's serviceable. On Fri, Nov 24, 2017 at 8:36 PM, T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote: > I am all for this. are many types where there is an obvious 'zero' or > 'default' value and the ability to express "use that when possible" without > an overload is welcome. > > > The best thing that I can think of right now, in terms of syntax, is > actually using @overload > > ``` > struct ResourceDescription<R: Resource> { > > func makeResource(with configuration: R.Configuration, actionHandler: > @escaping (R.Action) -> Void) -> R > @overload(R.Configuration == Void) func makeResource(actionHandler: > @escaping (R.Action) -> Void) -> R > @overload(R.Action == Never) func makeResource(with configuration: > R.Configuration) -> R > { > // create a resource using the provided configuration > // connect the action handler > // return the resource > } > } > ``` > > > This isn't great though… > > On Fri, Nov 24, 2017 at 6:11 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> As mentioned in my prior message, I currently have a PR open to update >> the generics manifesto (https://github.com/apple/swift/pull/13012). I >> removed one topic from that update at Doug Gregor’s request that it be >> discussed on the list first. >> >> The idea is to add the ability to make default arguments conditional >> (i.e. depend on generic constraints). It is currently possible to emulate >> conditional default arguments using an overload set. This is verbose, >> especially when several arguments are involved. Here is an example use >> case using the overload method to emulate this feature: >> >> ```swift >> protocol Resource { >> associatedtype Configuration >> associatedtype Action >> } >> struct ResourceDescription<R: Resource> { >> func makeResource(with configuration: R.Configuration, actionHandler: >> @escaping (R.Action) -> Void) -> R { >> // create a resource using the provided configuration >> // connect the action handler >> // return the resource >> } >> } >> >> extension ResourceDescription where R.Configuration == Void { >> func makeResource(actionHandler: @escaping (R.Action) -> Void) -> R { >> return makeResource(with: (), actionHandler: actionHandler) >> } >> } >> >> extension ResourceDescription where R.Action == Never { >> func makeResource(with configuration: R.Configuration) -> R { >> return makeResource(with: configuration, actionHandler: { _ in }) >> } >> } >> >> extension ResourceDescription where R.Configuration == Void, R.Action == >> Never { >> func makeResource() -> R { >> return makeResource(with: (), actionHandler: { _ in }) >> } >> } >> >> ``` >> >> Adding language support for defining these more directly would eliminate >> a lot of boilerplate and reduce the need for overloads. Doug mentioned >> that it may also help simplify associated type inference ( >> https://github.com/apple/swift/pull/13012#discussion_r152124535). >> >> The reason that I call this a pre-pitch and one reason Doug requested it >> be discussed on list is that I haven’t thought of a good way to express >> this syntactically. I am interested in hearing general feedback on the >> idea. I am also looking for syntax suggestions. >> >> Matthew >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution