> On Dec 21, 2017, at 10:59 AM, Dave Abrahams <dabrah...@apple.com> wrote: > > > >> On Dec 21, 2017, at 10:19 AM, Ethan Diamond <ethanjdiam...@gmail.com >> <mailto: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??
This was assigning .x to a, not evaluating a synthesized value > >> 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. > I’m not really sure what the problems synthesized properties are trying to solve are. Chris brought them up as a possible solution to my pain point, which they only solve partially. Checking for a case I don’t know up front (for example, comparing the cases of two values) still isn’t covered. >> >> >> >> 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
