<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I like the idea of a boolean expression! I think it is cleaner; the required if statement is a pain.</div><div class=""><br class=""></div><div class="">For the second idea, I’ve wondered if there could be some way of unwrapping the associated values:</div><div class=""><br class=""></div><div class="">case .foo(?) = bar</div><div class=""><br class=""></div><div class="">It would produce an optional. This would let you do:</div><div class=""><br class=""></div><div class="">let isAlan = (case .foo(?) = bar) == “Alan”</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">There’s also force unwrap:</div><div class=""><br class=""></div><div class="">let name = (case .foo(!) = bar)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Even better would be a way of unwrapping multiple values of the same type:</div><div class=""><br class=""></div><div class="">enum Bar {</div><div class=""> case foo(name: String)</div><div class=""> case goo(kind: GooKind, name: String)</div><div class=""><br class=""></div><div class=""> var name: String {</div><div class=""> return case .foo(!), .goo(_, !) = bar</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 10 May 2016, at 9:33 PM, Sam Dods via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I propose that <font face="Menlo" class=""><b class="">(case .Foo = bar)</b></font> should be treated as an expression with a Boolean value, so the result can be set to a variable or returned from a method.</div><div class=""><br class=""></div><div class="">Considering the following enumeration:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">enum Bar {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> case foo(name: String)</b></font></div><div class=""><font face="Menlo" class=""><b class=""> case notFoo</b></font></div><div class=""><font face="Menlo" class=""><b class=""> case unknownFoo</b></font></div><div class=""><font face="Menlo" class=""><b class="">}</b></font></div><div class=""><br class=""></div><div class="">Instead of having to do the following:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">func isBarFoo(bar: Bar) -> Bool {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> if case .Foo = bar {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> return true</b></font></div><div class=""><font face="Menlo" class=""><b class=""> }</b></font></div><div class=""><font face="Menlo" class=""><b class=""> return false</b></font></div><div class=""><font face="Menlo" class=""><b class="">}</b></font></div><div class=""><br class=""></div><div class="">We could simply do the following:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">func isBarFoo(bar: Bar) -> Bool {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> return (case .Foo = bar)</b></font></div><div class=""><font face="Menlo" class=""><b class="">}</b></font></div><div class=""><br class=""></div><div class="">We could also do things like this:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">let isBarFoo = (case .Foo = bar)</b></font></div><div class=""><font face="Menlo" class=""><b class="">XCTAssert(isBarFoo)</b></font></div><div class=""><br class=""></div><div class="">Of course, this change is only required for enumerations that don't have a raw value type (String, Int, etc).</div><div class=""><br class=""></div><div class="">It assumes the developer does not care what the associated value is, which could lead to issues. But this is already the case with the `<font face="Menlo" class=""><b class="">if case ... return true/false</b></font>` syntax. So it is not a degrading feature, just a more concise syntax for something that already exists.</div><div class=""><br class=""></div><div class="">Something to consider is whether `<font face="Menlo" class=""><b class="">case let ...</b></font>` could be treated as an expression in the same way. For example:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">if (case let .Foo(name) = bar) && name == "Alan" {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> return true</b></font></div><div class=""><font face="Menlo" class=""><b class="">}</b></font></div><div class=""><font face="Menlo" class=""><b class="">return false</b></font></div><div class=""><br class=""></div><div class="">The above could be simplified to:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">return (case let .Foo(name) = bar) && name == "Alan"</b></font></div><div class=""><br class=""></div><div class="">Due to the way AND-ed expression results are computed at runtime, the second expression would not be computed unless the first was true, so `<font face="Menlo" class=""><b class="">name</b></font>` must have a value. The compiler would know that when OR-ing expressions, the second expression is only computed if the first expression was false, so `<font face="Menlo" class=""><b class="">name</b></font>` definitely doesn't have a value:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">return (case let .Foo(name) = bar) || name == "Alan"</b></font></div><div class=""><br class=""></div><div class="">I would expect a compiler error similar to `<font face="Menlo" class=""><b class="">Variable declared in 'guard' condition is not usable in its body</b></font>`.</div><div class=""><br class=""></div><div class=""><div class="">What does everyone think of this? It would have no impact on existing code. </div></div><div class=""><br class=""></div><div class=""><br class=""></div><div style="font-size: 14px;" class=""><b class="">alternative, not proposing...</b></div><div class=""><br class=""></div><div class="">An alternative would be defaulting what equality means for enumerations, such that the `==` operator is automatically defined for enumerations in the following way:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><b class="">func ==(lhs: Bar, rhs: Bar) -> Bool {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> if case rhs = lhs {</b></font></div><div class=""><font face="Menlo" class=""><b class=""> return true</b></font></div><div class=""><font face="Menlo" class=""><b class=""> }</b></font></div><div class=""><font face="Menlo" class=""><b class=""> return false</b></font></div><div class=""><font face="Menlo" class=""><b class="">}</b></font></div><div class=""><br class=""></div><div class="">However, I think that having a default implementation for enum is a bad idea, because it's adding default behaviour that the developer might not know about. And this could lead to a less experienced developer making a mistake when comparing two enum values with associated values. Developers that know the `<font face="Menlo" class=""><b class="">if case ...</b></font>` syntax are already expected to understand that they are ignoring the associated value and they can use `<font face="Menlo" class=""><b class="">if case let ...</b></font>` if they care about the associated value. So my proposal is in-line with an existing expectation.</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><br class=""></font></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>