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

[Alex Lew]

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.

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?

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.

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?

-Alex

On Wed, Dec 9, 2015 at 12:45 AM, Chris Lattner <clattner at apple.com> wrote:

>
> > On Dec 7, 2015, at 8:05 PM, Alex Lew via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Hi all,
> >
> > Curious to hear thoughts on allowing non-binding pattern matches to be
> used as boolean values outside of an if, guard, for...in, while, switch,
> etc. Something like:
> >
> > enum List<T> {
> >      case Empty
> >      indirect case Link(T, List<T>)
> >
> >      func isEmpty() -> Bool {
> >           return case .Empty = self
> >      }
> > }
>
> I agree with you that this is a problem that we should solve, but I think
> it could be solved in a different way.  Imagine if:
>
> enum Foo {
>   case X(a : Float), Y, Z(a : Int)
> }
>
> automatically synthesized these members (the exact names are just a
> strawman proposal, not serious :-)
>
> extension Foo {
>   func isX() -> Float? {…}
>   func isY() -> Bool {…}
>   func isZ() -> Int? {…}
> }
>
> This would tie into all of the mechanics we have for dealing with
> optionals, e.g. if/let and ??
>
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/b93e9491/attachment.html>