> On Dec 21, 2017, at 10:19 AM, Ethan Diamond <ethanjdiam...@gmail.com> wrote:
>
> Just to clarify, Dave -
>
> What happens there if one case has associated values
> and one has an associated value thats an optional?
>
> Enum A {
> case x(String?)
> case y
> }
>
> let a = A.x(nil)
A.x is String??
> a.y // What's the result?
nil as Optional<Void>
> a.x // Would produce a double optional, which are clumsy to nil check
They’re a fact of life. If that’s a problem, we should consider fixing it, but
it’s orthogonal to this one.
>
> I'm not a fan of solving this via synthesis in general. We have metatypes for
> classes/structs/protocols, which are useful in all sorts of situations. Cases
> are essentially "types" of enums. Why not have case metatypes? They're useful
> for the same reasons class types are, and there's already precedence in the
> language for syntax.
You mean “precedent?” OK, but I don’t see how it helps with any of the same
problems as synthesized properties for cases do.
>
>
>
> On Thu, Dec 21, 2017 at 7:14 AM Dave Abrahams <dabrah...@apple.com
> <mailto:dabrah...@apple.com>> wrote:
> IIRC what we discussed was synthesizing members of type Optional<Payload>
> which could then be checked against nil.
>
> if _ = x.failure { ... }
> if x.failure != nil { ... }
> if let r = x.success {...}
>
> IMO synthesizing predicates would be a huge missed opportunity by comparison
>
> Sent from my iPhone
>
> On Dec 20, 2017, at 1:31 PM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> In the past, we’ve discussed synthesizing predicate members onto enums.
>> E.g. given:
>>
>> enum E {
>> case X
>> case Y(Int)
>> }
>>
>> you’d get something like:
>>
>> extension E {
>> func isX() -> Bool { return self == .X }
>> func getY() -> Int? { … }
>> }
>>
>> which would solve the client side of this nicely.
>>
>> -Chris
>>
>>
>>
>>> On Dec 20, 2017, at 11:24 AM, Ethan Diamond via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> Sorry all for attaching the original post to the Non-Exhaustive enums
>>> thread. I"m moving it down to it's own thread.
>>>
>>> My understanding is I'm not allowed to write up a proposal unless I have
>>> the time to implement it. Is that still true? This is a major pain point
>>> for me to avoid having to write things like this:
>>>
>>> if case .search = presenter.state { return true } else { return false }
>>>
>>> Side note: Thanks Kevin, didn't know you could nest enums in switches like
>>> that. Super helpful!
>>>
>>> ------------------------------------------------------
>>> I thought I would add another case that isn’t possible with current syntax
>>> (so far as I’m aware). You can’t negate the comparison to do something for
>>> all cases except a particular case. You have to have an empty if block and
>>> use the else block, or have an empty case in a switch statement and use the
>>> default.
>>>
>>> enum Enum {
>>> case a(param: String)
>>> case b(param: String)
>>> case c(param: String)
>>> }
>>>
>>> let enumeration: Enum = .a(param: "Hi")
>>>
>>> if !(case .a = enumeration) {
>>> // Do something
>>> }
>>>
>>> — Charles
>>>
>>> > On Dec 20, 2017, at 9:55 AM, Kevin Nattinger via swift-evolution
>>> > <swift-evolution at swift.org
>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
>>> >
>>> > I agree this would be useful. At the moment I have to hack around it with
>>> > things like `var isFoo: Bool { if case .foo = self …`* with cases I
>>> > commonly need, but this is definitely a feature that has come up before
>>> > and I support. It is potentially related to getting the values through an
>>> > accessor, which has also come up several times.
>>> >
>>> > Sidenote, your `switch` example is actually trivial with existing syntax:
>>> >
>>> > switch enumeration {
>>> > case .a(.c(let param)): // or just .a(.c) if you don't need the value
>>> > print(param)
>>> > default:
>>> > break
>>> > }
>>> >
>>> > I use this from time to time switching over, e.g., optional enums.
>>> >
>>> > *: ugliest syntax ever, and it can't even be used as a standalone
>>> > expression.
>>> >
>>> >
>>> >> On Dec 20, 2017, at 8:44 AM, Ethan Diamond via swift-evolution
>>> >> <swift-evolution at swift.org
>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> >> <mailto:swift-evolution at swift.org
>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
>>> >>
>>> >> Hello everyone,
>>> >>
>>> >> One major pain point I've run into with Swift is the inability to
>>> >> evaluate the case of an enum that has associated values in a way that
>>> >> just returns a bool. We've been given the ability in a switch statement:
>>> >>
>>> >> enum Enum {
>>> >> case a(param: String)
>>> >> case b(param: String)
>>> >> }
>>> >>
>>> >> let enumeration: Enum = a(param: "Hi")
>>> >> switch enumeration {
>>> >> case a:
>>> >> // Do something
>>> >> case b:
>>> >> // Do something
>>> >> }
>>> >>
>>> >> We'e been given the ability in the context of an if statement:
>>> >>
>>> >> enum Enum {
>>> >> case a(param: String)
>>> >> case b(param: String)
>>> >> }
>>> >>
>>> >> let enumeration: Enum = a(param: "Hi")
>>> >>
>>> >> if case .a = enumeration {
>>> >> // Do something
>>> >> }
>>> >>
>>> >> But without a basic was of getting a bool for if an enum is a given
>>> >> case, here's a list of things I can't do:
>>> >>
>>> >> Where statements:
>>> >>
>>> >> enum Enum {
>>> >> case a(param: Enum2)
>>> >> case b(param: Enum2)
>>> >> }
>>> >>
>>> >> enum Enum2 {
>>> >> case c(param: String)
>>> >> case d(param: String)
>>> >> }
>>> >>
>>> >> let enumeration: Enum = a(param: "Hi")
>>> >> switch enumeration {
>>> >> case a(let inner) where [INNER CASE IS .c]
>>> >> }
>>> >>
>>> >> ---------
>>> >>
>>> >> Filter an array for a certain case:
>>> >>
>>> >> Expertly explained by Erica Sadun here:
>>> >> http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/
>>> >>
>>> >> <http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/>
>>> >>
>>> >> <http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/
>>> >>
>>> >> <http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/>>
>>> >>
>>> >> ---------
>>> >>
>>> >> Nicely set a UIButton to hidden if an enum is a certain case:
>>> >>
>>> >> enum State {
>>> >> case `default`
>>> >> case searching(results: [Result])
>>> >> }
>>> >>
>>> >> myButton.isHidden = [STATE IS .searching]
>>> >>
>>> >> ---------
>>> >>
>>> >> I've run into this issue a ton of times because I tend to represent my
>>> >> views a State enums. I haven't seen anything on the board for plans for
>>> >> solving this issue, thought. Has there been any discussion about
>>> >> addressing it? Ideally I'd be able to do this:
>>> >>
>>> >> enum Enum {
>>> >> case a(param: String)
>>> >> case b(param: String)
>>> >> }
>>> >>
>>> >> let enumeration: Enum = a(param: "Hi")
>>> >>
>>> >> case .a = enumeration // Bool
>>> >> case .a(let param) = enumeration // Bool, assigns "Hi" to "param"
>>> >>
>>> >> Thanks!
>>> >> Ethan
>>> >>
>>> >> _______________________________________________
>>> >> swift-evolution mailing list
>>> >> swift-evolution at swift.org
>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> >> <mailto:swift-evolution at swift.org
>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>>
>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> >
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org
>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>_______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
