Re: [swift-evolution] Testing enum cases with associated values

I agree it’s overkill for what I’m really looking for, which is a simple way to get a Bool result from testing an enum against a specific case, without looking at the associated values. Andy > On Jan 18, 2017, at 10:15 AM, Tony Allevato wrote: > > FWIW, I'm not convinced that making enum valu

Re: [swift-evolution] Testing enum cases with associated values

FWIW, I'm not convinced that making enum values look like structs with optional properties for the union of all their cases is a good idea. It's certainly not something I would want added to all of my enums by default, and it feels IMO like it's just an awkward hack around the fact that pattern mat

Re: [swift-evolution] Testing enum cases with associated values

That’s an interesting proposal. Here’s a link for reference: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027287.html The one thing is the proposed syntax doesn’t handle enum cases wi

Re: [swift-evolution] Testing enum cases with associated values

This is nice, but it doesn’t solve the issue at hand because there is only one enum value. I would like to have something like: if value == .TWO { … } I can’t use this == operator for this because I’d have to create: if value == .TWO(str) { … } But I don’t have a specific str,

Re: [swift-evolution] Testing enum cases with associated values

The last time I was in this situation, I resolved it by having a shadow enum with the same cases but without any associated value. I also created shadow enums for error enums. The shadow enum wouldn't have any associated value, and Int as RawValue, and I would also use it as an error code when

Re: [swift-evolution] Testing enum cases with associated values

AFAICS, Andy needs not default implementations of Equatable, but cases-as-optional-properties—this topic has also been discussed on the list. enum Result { case success(Int) case failure(String) } let r: Result = foo() let x: Int? = r.success let y: String? = r.failure assert(r.success

Re: [swift-evolution] Testing enum cases with associated values

A guy named Matthias recently commented this on my blog: func == (left: Enum3, right: Enum3) -> Bool { switch (left, right) { case (.ONE, .ONE): return true case (.TWO(let str1), .TWO(let str2)): return str1 == str2 default: return false } } http://swiftrien.blogspot.nl/2015/05/swift-enum-compare

Re: [swift-evolution] Testing enum cases with associated values

> if request == .failure { ... } Typo. It should read if result == .failure { ... } ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Testing enum cases with associated values

I see your point about conformances. In my example, AuthenticationResponse isn't a generic type, so the conformances spec won't apply. I'll go out on a limb and say that 80%+ of the use cases for equality will be to distinguish enum cases, not the associated values. I do like your proposal thou

Re: [swift-evolution] Testing enum cases with associated values

Conditional conformances doesn't solve enum equality though, because there likely won't be a way to utter "enum Foo : Equatable where " with the generics syntax that's available, and conformance alone wouldn't be able to derive the implementation. It'll require some work on the compiler's part to g

Re: [swift-evolution] Testing enum cases with associated values

This is distinct from conditional conformances (we could add this feature today). ~Robert Widmann > On Jan 17, 2017, at 8:59 PM, Andy Chou wrote: > > Yes, here's a reference to the conditional conformance proposal which was > accepted: > > https://github.com/apple/swift-evolution/blob/master

Re: [swift-evolution] Testing enum cases with associated values

Yes, here's a reference to the conditional conformance proposal which was accepted: https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md But as I mention

Re: [swift-evolution] Testing enum cases with associated values

Automatic “equatability” of aggregates that contain equatable members has been discussed on this list quite a few times. (I think I had a branch at one point that was exploring this kind of deriving mechanism… It seems to be lost to the sands of time). Everybody seems to agree that it’s a wort