Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Ethan Diamond via swift-evolution]

> On Dec 21, 2017, at 10:59 AM, Dave Abrahams  wrote:
> 
> 
> 
>> On Dec 21, 2017, at 10:19 AM, Ethan Diamond > > 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
> 
>> 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 > > wrote:
>> IIRC what we discussed was synthesizing  members of type Optional 
>> 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 
>> 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 
 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 
 > >>> > > 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 
 >> >>> >>  
 >> > 

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Ethan Diamond via swift-evolution]

Is there a reason the team wants to do synthesis instead of other options? If 
that’s no longer assignment, it’s going to break a lot of code. 

Sent from my iPhone

> On Dec 23, 2017, at 1:19 PM, Dave Abrahams  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Dec 21, 2017, at 2:33 PM, Ethan Diamond  wrote:
>> 
>> 
>>> On Dec 21, 2017, at 10:59 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> 
 On Dec 21, 2017, at 10:19 AM, Ethan Diamond  
 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
>>> 
 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  wrote:
> IIRC what we discussed was synthesizing  members of type 
> Optional 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 
>>  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 
>>>  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 
>>> >  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 {

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Dave Abrahams via swift-evolution]

Sent from my iPhone

> On Dec 21, 2017, at 2:33 PM, Ethan Diamond  wrote:
> 
> 
>> On Dec 21, 2017, at 10:59 AM, Dave Abrahams  wrote:
>> 
>> 
>> 
>>> On Dec 21, 2017, at 10:19 AM, Ethan Diamond  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
>> 
>>> 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  wrote:
 IIRC what we discussed was synthesizing  members of type Optional 
 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 
>  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 
>>  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 
>> >  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 De

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Djura Retired Hunter via swift-evolution]

Many styles of programming can take advantage of if/else and switch/case being 
actual expressions (actually, these are all special cases of the very general 
concept of "folding"). We don't have this in Swift, and I have occasion to be 
bothered by this almost on a daily basis in my work, especially when I try to 
be "concise", something for which Swift should be champion.

The best possible outcome would be for Swift to have pattern matching as a 
proper evaluated expression, but I would accept a new operator that takes 
advantage of some custom compiler magic, because the use cases are so many and 
the convenience would be so great.

As Colin Barret said, this is a very popular thing in many modern languages.


Elviro

> Il giorno 20 dic 2017, alle ore 19:32, Colin Barrett via swift-evolution 
>  ha scritto:
> 
> This would be easily solved if pattern matching was available as an 
> expression, such as in Haskell, OCaml / Standard ML, and Scala / Kotlin. :-)
> 
>> On Dec 20, 2017, at 11:44 AM, Ethan Diamond via swift-evolution 
>> mailto:swift-evolution@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/
>>  
>> 
>> 
>> -
>> 
>> 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@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

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Dave Abrahams via swift-evolution]

> On Dec 21, 2017, at 10:19 AM, Ethan Diamond  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

> 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  > wrote:
> IIRC what we discussed was synthesizing  members of type Optional 
> 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 
> 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 
>>> 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 
>>> > >> > > 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 
>>> >> >> >>  
>>> >> >> >> >> 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'

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Ethan Diamond via swift-evolution]

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.y // What's the result?
a.x // Would produce a double optional, which are clumsy to nil check

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.



On Thu, Dec 21, 2017 at 7:14 AM Dave Abrahams  wrote:

> IIRC what we discussed was synthesizing  members of type Optional
> 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 
> > >> 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 
>   
>  >> 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")

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Dave Abrahams via swift-evolution]

IIRC what we discussed was synthesizing  members of type Optional 
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 
>  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 
>>  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 
>> >  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 
>> >> 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/
>> >>  
>> >> 
>> >> 
>> >> -
>> >> 
>> >> 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 Sta

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Lustyik Tamás via swift-evolution]

There was a similar thread early this year which I tried to resurrect like
a month ago. In my reply I suggested freeing pattern matching from control
statements and allowing any pattern matching expression to be evaluated as
a boolean. Let me quote what I wrote there:

<< {
case success(T)
case failure
}

let r = Result.success(42)
let rs: [Result] = [.success(2), .success(3), .failure, .success(5),
.failure]

let simpleTest: Bool = (case .success = r)
let simpleFiltered: [Result] = rs.filter { case .success = $0 }

Now, we could take this even further and allow matching for subparts:

let subpartTest: Bool = (case .success(let v) = r, v < 100)
// --> true
let subpartFiltered: [Result] = rs.filter { case .success(let v) = $0,
v % 2 == 1 }
// --> [.success(3), .success(5)]

or perhaps with a more verbose syntax:

let subpartTest2: Bool = (case .success(let v) = r where v < 100)
let subpartFiltered2: [Result] = rs.filter { case .success(let v) = $0
where v % 2 == 1 }

I'm not familiar with the parsing challenges of the above suggestion but
these expressions don't look wildly different from what we already see in
currently supported pattern matching constructs.

QUOTE

So what do you think of this approach? To me it looks less clumsy than
generating "getXY"-style accessors.

Tamas



On Thu, Dec 21, 2017 at 1:50 AM, Ethan Diamond via swift-evolution <
swift-evolution@swift.org> wrote:

> It feels like it solves my current problem in a way that's almost as
> undesirable as the current solution. Say I have:
>
> Enum A {
>case x(String?)
>case y(String)
> }
>
> Right now I have code like this peppered throughout my code, which I think
> we can agree is pretty undesirable:
>
> if let case .x = value { return true } else { return false }
>
> I actually think that new syntax would be worse. It's not obvious what
> this does:
>
> if let string = value.getX() {
> return string != nil
> } else {
> return false
> }
>
> Even aside from readability, it strikes me as very weird that we have
> clean syntax for cases that ignore associated values inside of switch, if
> and guard statements, but outside of them we need to always write code
> around the associated value even when the associated values don't matter to
> what we're trying to do. I'm not going to pretend it's something I hit
> every day, but it's something I do *fairly* often, and it always feels like
> I'm fighting the language to do it.
>
> Having an isX() would be a big improvement, and I think we'd happily take
> it. That being said, any of these are the code I would ideally want to
> write:
>
> let a: A = .x("String")
>
> a.matches(.x) // true
> a.matches(.x(_)) // true
> a.matches(.x("Taco") // false
>
> or
>
> case(of: a) == .x // true (my personal favorite)
>
> or
>
> case a == .x // true
>
>
> On Wed, Dec 20, 2017 at 3:11 PM Chris Lattner  wrote:
>
>> On Dec 20, 2017, at 2:12 PM, Ethan Diamond 
>> wrote:
>>
>> Would that synthesize an isY() even though .Y has an associated value
>> there?
>>
>>
>> I’m not aware of a concrete design for this idea.  The details would
>> definitely need to be figured out, but I don’t see why a double optional is
>> itself a problem.
>>
>> -Chris
>>
>>
>> enum E {
>> case X
>> case Y(Int?)
>> }
>>
>> If I had to run that through getY() -> Int??, it still wouldn't be quite
>> what I was looking for with regards to intent. If you are planning an doing
>> an isY though, that would work for most cases where you're evaluating for a
>> given enum and know what it is beforehand. Even so that wouldn't work for a
>> case, for example, where I'm trying to see if two enums are the same case,
>> and don't necessarily care if they're equal.
>>
>> let value1 = E.Y(1)
>> let value2 = E.Y(2)
>>
>> value1 == value2 // false
>> value1 [is the same case as] value 2 // how do I get this?
>>
>> This would be useful, say, if I was trying to generate a diff of two
>> arrays of enums, which I occasionally do for table / collection views to
>> figure out inserts/removals/updates.
>>
>> I don't necessarily know if it's feasible, but it would be really great
>> to have something like a Case metatype, the same way we have type(of: ). It
>> would be great to have a case(of: ) that we can evaluate against the
>> shorthand like we do in switch statements.
>>
>> Ex:
>>
>> case(of: value1) == .Y // true
>> case(of: value1) == .X // false
>> case(of: value1) == case(of: value2) // true
>>
>>
>>
>> On Wed, Dec 20, 2017 at 1:31 PM Chris Lattner 
>> 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

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[David Hart via swift-evolution]

> On 20 Dec 2017, at 20:24, Ethan Diamond via swift-evolution 
> 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:

All proposals need an implementation before they can go through the final 
review stage, but the proposal author doesn’t also have to be the implementor.
> 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 
> >  > > 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 
> >>  >>  
> >>  >> >> 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/
> >>  
> >> 
> >>  
> >>  >>  
> >> >
> >> 
> >> -
> >> 
> >> 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

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Ethan Diamond via swift-evolution]

It feels like it solves my current problem in a way that's almost as
undesirable as the current solution. Say I have:

Enum A {
   case x(String?)
   case y(String)
}

Right now I have code like this peppered throughout my code, which I think
we can agree is pretty undesirable:

if let case .x = value { return true } else { return false }

I actually think that new syntax would be worse. It's not obvious what this
does:

if let string = value.getX() {
return string != nil
} else {
return false
}

Even aside from readability, it strikes me as very weird that we have clean
syntax for cases that ignore associated values inside of switch, if and
guard statements, but outside of them we need to always write code around
the associated value even when the associated values don't matter to what
we're trying to do. I'm not going to pretend it's something I hit every
day, but it's something I do *fairly* often, and it always feels like I'm
fighting the language to do it.

Having an isX() would be a big improvement, and I think we'd happily take
it. That being said, any of these are the code I would ideally want to
write:

let a: A = .x("String")

a.matches(.x) // true
a.matches(.x(_)) // true
a.matches(.x("Taco") // false

or

case(of: a) == .x // true (my personal favorite)

or

case a == .x // true


On Wed, Dec 20, 2017 at 3:11 PM Chris Lattner  wrote:

> On Dec 20, 2017, at 2:12 PM, Ethan Diamond 
> wrote:
>
> Would that synthesize an isY() even though .Y has an associated value
> there?
>
>
> I’m not aware of a concrete design for this idea.  The details would
> definitely need to be figured out, but I don’t see why a double optional is
> itself a problem.
>
> -Chris
>
>
> enum E {
> case X
> case Y(Int?)
> }
>
> If I had to run that through getY() -> Int??, it still wouldn't be quite
> what I was looking for with regards to intent. If you are planning an doing
> an isY though, that would work for most cases where you're evaluating for a
> given enum and know what it is beforehand. Even so that wouldn't work for a
> case, for example, where I'm trying to see if two enums are the same case,
> and don't necessarily care if they're equal.
>
> let value1 = E.Y(1)
> let value2 = E.Y(2)
>
> value1 == value2 // false
> value1 [is the same case as] value 2 // how do I get this?
>
> This would be useful, say, if I was trying to generate a diff of two
> arrays of enums, which I occasionally do for table / collection views to
> figure out inserts/removals/updates.
>
> I don't necessarily know if it's feasible, but it would be really great to
> have something like a Case metatype, the same way we have type(of: ). It
> would be great to have a case(of: ) that we can evaluate against the
> shorthand like we do in switch statements.
>
> Ex:
>
> case(of: value1) == .Y // true
> case(of: value1) == .X // false
> case(of: value1) == case(of: value2) // true
>
>
>
> On Wed, Dec 20, 2017 at 1:31 PM Chris Lattner  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 
>> >> >> 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 th

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Chris Lattner via swift-evolution]

> On Dec 20, 2017, at 2:12 PM, Ethan Diamond  wrote:
> 
> Would that synthesize an isY() even though .Y has an associated value there?

I’m not aware of a concrete design for this idea.  The details would definitely 
need to be figured out, but I don’t see why a double optional is itself a 
problem.

-Chris

> 
> enum E {
> case X
> case Y(Int?)
> }
> 
> If I had to run that through getY() -> Int??, it still wouldn't be quite what 
> I was looking for with regards to intent. If you are planning an doing an isY 
> though, that would work for most cases where you're evaluating for a given 
> enum and know what it is beforehand. Even so that wouldn't work for a case, 
> for example, where I'm trying to see if two enums are the same case, and 
> don't necessarily care if they're equal.
> 
> let value1 = E.Y(1)
> let value2 = E.Y(2)
> 
> value1 == value2 // false
> value1 [is the same case as] value 2 // how do I get this?
> 
> This would be useful, say, if I was trying to generate a diff of two arrays 
> of enums, which I occasionally do for table / collection views to figure out 
> inserts/removals/updates.
> 
> I don't necessarily know if it's feasible, but it would be really great to 
> have something like a Case metatype, the same way we have type(of: ). It 
> would be great to have a case(of: ) that we can evaluate against the 
> shorthand like we do in switch statements. 
> 
> Ex: 
> 
> case(of: value1) == .Y // true
> case(of: value1) == .X // false
> case(of: value1) == case(of: value2) // true
> 
> 
> 
> On Wed, Dec 20, 2017 at 1:31 PM Chris Lattner  > 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 
>> 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 
>> > > > > 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 
>> >> > >>  
>> >> > >> >> 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
>> >> }
>> >> 

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Ethan Diamond via swift-evolution]

Would that synthesize an isY() even though .Y has an associated value there?

enum E {
case X
case Y(Int?)
}

If I had to run that through getY() -> Int??, it still wouldn't be quite
what I was looking for with regards to intent. If you are planning an doing
an isY though, that would work for most cases where you're evaluating for a
given enum and know what it is beforehand. Even so that wouldn't work for a
case, for example, where I'm trying to see if two enums are the same case,
and don't necessarily care if they're equal.

let value1 = E.Y(1)
let value2 = E.Y(2)

value1 == value2 // false
value1 [is the same case as] value 2 // how do I get this?

This would be useful, say, if I was trying to generate a diff of two arrays
of enums, which I occasionally do for table / collection views to figure
out inserts/removals/updates.

I don't necessarily know if it's feasible, but it would be really great to
have something like a Case metatype, the same way we have type(of: ). It
would be great to have a case(of: ) that we can evaluate against the
shorthand like we do in switch statements.

Ex:

case(of: value1) == .Y // true
case(of: value1) == .X // false
case(of: value1) == case(of: value2) // true



On Wed, Dec 20, 2017 at 1:31 PM Chris Lattner  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 
> > >> 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 
>   
>  >> 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: En

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Chris Lattner via swift-evolution]

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 
>  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 
> >  > > 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 
> >>  >>  
> >>  >> >> 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/
> >>  
> >> 
> >>  
> >>  >>  
> >> >
> >> 
> >> -
> >> 
> >> 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?

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Colin Barrett via swift-evolution]

This would be easily solved if pattern matching was available as an expression, 
such as in Haskell, OCaml / Standard ML, and Scala / Kotlin. :-)

> On Dec 20, 2017, at 11:44 AM, Ethan Diamond via 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/
>  
> 
> 
> -
> 
> 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@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

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Charles Augustine via swift-evolution]

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 
>  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 
>> mailto:swift-evolution@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/
>>  
>> 
>> 
>> -
>> 
>> 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@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

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Kevin Nattinger via swift-evolution]

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 
>  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/
>  
> 
> 
> -
> 
> 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@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