[swift-evolution] Closures from methods with default args

Slava Pestov spestov at apple.com
Fri Jan 20 00:41:41 CST 2017


> On Jan 19, 2017, at 9:07 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:

> It causes other issues, too. For instance, if we have
>     protocol Initable { init() }
> And
>     struct Foo { init(_ x: Int = 0) {} }
> We're left in an odd situation where `Foo`  can't meaningfully conform to `Initable` because while "init(_: Int = 0)" is not the same as "init()", if you add a "init()" to `Foo`
> you'll get an ambiguous somethingerather error because there's no mechanism for the compiler to know whether you want the actual "0 argument" function or the "1 argument with 1 default value" function.
> 
> Aside from re-architecting the default argument system (which I'm not even sure is possible, let alone a good idea), I think I see couple ways forward for the protocol conformance issue. Both have downsides, though.
> 
> 1) Require any potentially conflicting protocol functions to be in an extension so the compiler knows what's going on, have "Foo()" call the one defined in the type, and use "(Foo as Initable)()" for the protocol version defined in an extension. This could get real confusing real fast if people don't realize there's two functions with, as far as they can tell, the same signature.
> 
> 2) Add default argument support to protocols. The syntax that makes sense to me would be something like
>     protocol Bar {
>         func baz(_: Int = _)
>     }
> On the downside, I suspect this would necessarily add a phantom "Self or associated type requirement" so that the compiler could have a way to get at each implementation's default value. It's not ideal... You'd get an error kinda out of the blue if you tried to use the function non-generically, but at least you couldn't have a function change out from under you.

I think in this specific example, the best solution is to allow init(_ x: Int = 0) to witness the init() requirement, and have the compiler emit the necessary glue in-between so that a call to the init() requirement calls init(_) with the appropriate default value. This will address the ‘ambiguous reference’ issue, and should not require too much work to implement. I am also inclined to believe this is (mostly) a source-compatible change. It also fits in with the current default argument model, but Doug Gregor can correct me if I’m wrong.

If anyone is interested, the code for matching protocol requirements to witnesses is in lib/Sema/TypeCheckProtocol.cpp, matchWitness() and surrounding functions, and the code for emitting a protocol witness thunk (where you would actually apply the default arguments) is in lib/SILGen/SILGenPoly.cpp, emitProtocolWitness(). It would be a good not-quite-starter-project ;-)

Slava

> 
> - Dave Sweeris 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170119/a33e6045/attachment.html>


More information about the swift-evolution mailing list