[swift-evolution] [proposal] Treat (case .Foo = bar) as a Boolean expression

[Vladimir.S]

Personally I feel like this construction "case .foo = bar" is alien in 
Swift.. Is it assignment ? No. Is it equality sign? No, we use '==' when 
checking for the equality. Is it clear what does this construction mean?
I'd like to see at least something like `bar is case .foo` or `bar in case 
.foo`

IMO I prefer to change this construction at all, and do not propose 
extension of its usage. For example, Bar.checkCase(.foo, for: bar) or 
bar.isCase(.foo)... And actually we need to improve enums in Swift., do we 
have proposals?

Why don't use in your example:
switch bar {
case .foo : return true
default : return false
}

Probably we should introduce `switch` that is expression, so we can use

let f = switch bar { case .foo : true; default : false }

But not this IMO ugly construction "case .foo = bar"

On 10.05.2016 14:33, Sam Dods via swift-evolution 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>