I like Tony's idea. Maybe the default argument functions could even take arguments with earlier parameters from the parameter list.
-Thorsten > Am 25.11.2017 um 20:28 schrieb Tony Allevato via swift-evolution > <[email protected]>: > >> On Fri, Nov 24, 2017 at 7:18 PM Xiaodi Wu via swift-evolution >> <[email protected]> wrote: >> >> 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. > > What if we could take advantage of the fact that you can have non-constant > expressions in default arguments? Overload resolution could already do most > of the job—what we need on top of that is a way for the author to say that > “if no overload matches, then it’s not an error—just don’t have a default > argument in that case”. Something like SFINAE in C++, but more explicit. > > I’m imagining something like this: > > func defaultConfiguration() -> Void { > return () > } > > func defaultActionHandler() -> (Never) -> Void { > return { _ in } > } > > struct ResourceDescription<R: Resource> { > func makeResource( > with configuration: R.Configuration =? defaultConfiguration(), > actionHandler: @escaping (R.Action) -> Void =? defaultActionHandler() > ) -> R { > // create a resource using the provided configuration > // connect the action handler > // return the resource > } > } > The main difference here is the strawman =? syntax, which would indicate that > “the default argument exists if there is a way the RHS can be satisfied for > some instances of the generic arguments; otherwise, there is no default”, > instead of today’s behavior where it would be an error. There could be > multiple overloads of defaultConfiguration and defaultActionHandler (even > ones that are themselves generic) and it would do the right thing when there > are matches and when there aren’t. > > I like this approach because it mostly takes advantage of existing language > features and is fairly lightweight in terms of how it’s expressed in code > compared to regular default arguments—we’d just need to design the new > operator and type-checker logic around it. > > > >> >> >>> On Fri, Nov 24, 2017 at 8:36 PM, T.J. Usiyan via swift-evolution >>> <[email protected]> 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 >>>> <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
