<div dir="ltr">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.<div><br><div><div>Brainstorming some names for the auto-generated functions:</div><div><br></div><div>1. If a case has no associated values, isX() -> Bool is generated, where X is the case name.</div><div> If a case has an associated value of type T, asX() -> T? is generated, where X is the case name.</div></div><div> This mirrors is/as? operators, which return Bool / Optional respectively.</div><div>2. projectX() -> Bool / projectX() -> T?</div><div>3. isX() -> Bool / xValue() -> T?</div><div><br></div><div>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.</div><div><br></div><div><div>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</div><div><br></div><div>case Dog(name: String, age: Int, breed: String)</div><div><br></div><div>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?</div></div><div><br></div><div>-Alex</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 12:45 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Dec 7, 2015, at 8:05 PM, Alex Lew via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> 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:<br>
><br>
> enum List<T> {<br>
> case Empty<br>
> indirect case Link(T, List<T>)<br>
><br>
> func isEmpty() -> Bool {<br>
> return case .Empty = self<br>
> }<br>
> }<br>
<br>
</span>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:<br>
<br>
enum Foo {<br>
case X(a : Float), Y, Z(a : Int)<br>
}<br>
<br>
automatically synthesized these members (the exact names are just a strawman proposal, not serious :-)<br>
<br>
extension Foo {<br>
func isX() -> Float? {…}<br>
func isY() -> Bool {…}<br>
func isZ() -> Int? {…}<br>
}<br>
<br>
This would tie into all of the mechanics we have for dealing with optionals, e.g. if/let and ??<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris</font></span></blockquote></div><br></div>