I like the idea of a boolean expression! I think it is cleaner; the required if
statement is a pain.
For the second idea, I’ve wondered if there could be some way of unwrapping the
associated values:
case .foo(?) = bar
It would produce an optional. This would let you do:
let isAlan = (case .foo(?) = bar) == “Alan”
There’s also force unwrap:
let name = (case .foo(!) = bar)
Even better would be a way of unwrapping multiple values of the same type:
enum Bar {
case foo(name: String)
case goo(kind: GooKind, name: String)
var name: String {
return case .foo(!), .goo(_, !) = bar
}
}
> On 10 May 2016, at 9:33 PM, Sam Dods via swift-evolution
> <[email protected]> wrote:
>
> I propose that (case .Foo = bar) should be treated as an expression with a
> Boolean value, so the result can be set to a variable or returned from a
> method.
>
> Considering the following enumeration:
>
> enum Bar {
> case foo(name: String)
> case notFoo
> case unknownFoo
> }
>
> Instead of having to do the following:
>
> func isBarFoo(bar: Bar) -> Bool {
> if case .Foo = bar {
> return true
> }
> return false
> }
>
> We could simply do the following:
>
> func isBarFoo(bar: Bar) -> Bool {
> return (case .Foo = bar)
> }
>
> We could also do things like this:
>
> let isBarFoo = (case .Foo = bar)
> XCTAssert(isBarFoo)
>
> Of course, this change is only required for enumerations that don't have a
> raw value type (String, Int, etc).
>
> 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 `if case ...
> return true/false` syntax. So it is not a degrading feature, just a more
> concise syntax for something that already exists.
>
> Something to consider is whether `case let ...` could be treated as an
> expression in the same way. For example:
>
> if (case let .Foo(name) = bar) && name == "Alan" {
> return true
> }
> return false
>
> The above could be simplified to:
>
> return (case let .Foo(name) = bar) && name == "Alan"
>
> 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 `name` 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
> `name` definitely doesn't have a value:
>
> return (case let .Foo(name) = bar) || name == "Alan"
>
> I would expect a compiler error similar to `Variable declared in 'guard'
> condition is not usable in its body`.
>
> What does everyone think of this? It would have no impact on existing code.
>
>
> alternative, not proposing...
>
> An alternative would be defaulting what equality means for enumerations, such
> that the `==` operator is automatically defined for enumerations in the
> following way:
>
> func ==(lhs: Bar, rhs: Bar) -> Bool {
> if case rhs = lhs {
> return true
> }
> return false
> }
>
> 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 `if case ...` syntax are already expected to understand that they are
> ignoring the associated value and they can use `if case let ...` if they care
> about the associated value. So my proposal is in-line with an existing
> expectation.
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
