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

[Jonathan Hull]

I have wanted something similar to this for a while, and haven’t suggested it for a while for the same reason… I can’t really think of a good syntax.

My best idea so far is to put it after the function declaration but before the open brace:

	func myCrazyFunction<T>(myParam: T)->Int
	@default myParam = 0 where T == Int.Self
	@default myParam = “” where T == String.Self
	{
		//Function body goes here
	}

When multiple options are available, it would match the most specific one that qualifies.  The idea I had would also allow it to have expressions on the rhs, and would potentially allow other input types outside of T (as long as the rhs returns T):

	func evenCrazier(myParam: String)->Int
	@default myParam = “\($0)” where myParam : CustomStringConvertible
	{
		//Function body goes here
	}

There are some obvious issues with the syntax here (e.g. I am using $0), but I think the general idea is a really useful one.  That is, I am able to provide a conversion formula that lets someone pass anything which is customStringConvertible to this String parameter and have it pass the appropriate String to my actual function. I would use this constantly, and it would prevent the combinatorial explosion of overloads I have now…

This also gets rid of the need for the often-requested-but-never-going-to-happen union types:

	enum MyEnum {
		case int (Int)
		case str (String)
	}

	func noNeedForUnion(_ intOrStr: MyEnum)
	@default intOrStr = .int($0) where intOrStr == Int.Self
	@default intOrStr = .str($0) where intOrStr == String.Self
	{
		//Function body here
	}

	noNeedForUnion(3) //This passes .int(3)
	noNeedForUnion(“Hey”) //this passes .str(“Hey”)

I could see this making a bunch of frameworks nicer to use… (or at least nicer to write)

Thanks,
Jon


> On Nov 24, 2017, at 3: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 <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 <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/20171126/ff62f770/attachment.html>