[swift-evolution] [Pre-pitch] Conditional default arguments
T.J. Usiyan
griotspeak at gmail.com
Fri Nov 24 20:36:51 CST 2017
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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171124/b72cf57a/attachment.html>
More information about the swift-evolution
mailing list