Sent from my iPhone
> On Dec 21, 2017, at 2:33 PM, Ethan Diamond <ethan.j.diam...@gmail.com> wrote: > > >> 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> 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 And I was making an assertion, not asking a question š > >> >>> 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> 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> 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> 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> 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 <mailto:swift-evolution at swift.org>> >>>>>> >> 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/> >>>>>> >> >>>>>> >> --------- >>>>>> >> >>>>>> >> 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 <mailto:swift-evolution at swift.org> >>>>>> >> 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 >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution