[swift-evolution] Allowing non-binding pattern matching as a Bool expression?

Chris Lattner clattner at apple.com
Thu Dec 10 23:36:35 CST 2015


On Dec 8, 2015, at 10:29 PM, Alex Lew <alexl.mail+swift at gmail.com> wrote:
> Thanks, Chris, for all the time you're putting into responding to these proposals (and the kindness with which you're responding!). I really like that solution.

Happy to help.

> Brainstorming some names for the auto-generated functions:
> 
> 1. If a case has no associated values, isX() -> Bool is generated, where X is the case name.
>     If a case has an associated value of type T, asX() -> T? is generated, where X is the case name.
>     This mirrors is/as? operators, which return Bool / Optional respectively.
> 2. projectX() -> Bool / projectX() -> T?
> 3. isX() -> Bool / xValue() -> T?

MHO, I like #1 with isX/asX - good idea.

> Another option (probably the wrong option, but it's worth putting out there) is that instead of returning Bool in the no-associated-value case, we return ()?. This would make me feel better about using the same naming convention (asX(), projectX(), xValue(), etc.) for each case, and would allow for != nil checks on all cases. But it would probably be a little confusing for newcomers to the language.

I can see that argument, but I think it would both be surprising/weird but would also be less useful.  You’d have to do things like:
	if myEnum.asX() != nil {
instead of:
	if myEnum.isX() {

Similarly, the ??, if let, and other mechanics that work with optionals wouldn’t be helpful here, since you’d never want to bind the void value.

> One (potentially misguided) question. I noticed in proposal 0002 (on removing function currying) that there are "plans to move away from the arguments-are-a-single-tuple model" in the near future. Would this also affect associated values of enums? That is, might
> 
> case Dog(name: String, age: Int, breed: String)
> 
> one day not have the semantics of a single associated value of type (name: String, age: Int, breed: String)? Or is the de-ML-ification planned only for function arguments?

No, enum cases should retain their argument lists.  It is not related.

-Chris



More information about the swift-evolution mailing list