[swift-evolution] [Pre-pitch] Conditional default arguments

[Xiaodi Wu]

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 at 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 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
>>
>>
>
> _______________________________________________
> 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/6396149e/attachment.html>