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
> <[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
> <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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
