[swift-evolution] Allowing non-binding pattern matching as a Bool expression?

[Chris Lattner]

> On Dec 9, 2015, at 8:49 AM, thorsten at portableinnovations.de wrote:
> 
> I would prefer if no "magic" methods would be generated automatically, but only when marked with @derivestandardmethods (fill in better name here).

Yes, making it opt-in could make sense.

> What about enums with more than one associated value?

It would return an optional tuple of the associated values, the tuple corresponds to the case parameter list.

-Chris



> 
> -Thorsten
> 
> Am 09.12.2015 um 07:29 schrieb Alex Lew via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> 
>> Thanks, Chris, for all the time you're putting into responding to these proposals (and the kindness with which you're responding!). I really like that solution.
>> 
>> Brainstorming some names for the auto-generated functions:
>> 
>> 1. If a case has no associated values, isX() -> Bool is generated, where X is the case name.
>>     If a case has an associated value of type T, asX() -> T? is generated, where X is the case name.
>>     This mirrors is/as? operators, which return Bool / Optional respectively.
>> 2. projectX() -> Bool / projectX() -> T?
>> 3. isX() -> Bool / xValue() -> T?
>> 
>> Another option (probably the wrong option, but it's worth putting out there) is that instead of returning Bool in the no-associated-value case, we return ()?. This would make me feel better about using the same naming convention (asX(), projectX(), xValue(), etc.) for each case, and would allow for != nil checks on all cases. But it would probably be a little confusing for newcomers to the language.
>> 
>> One (potentially misguided) question. I noticed in proposal 0002 (on removing function currying) that there are "plans to move away from the arguments-are-a-single-tuple model" in the near future. Would this also affect associated values of enums? That is, might
>> 
>> case Dog(name: String, age: Int, breed: String)
>> 
>> one day not have the semantics of a single associated value of type (name: String, age: Int, breed: String)? Or is the de-ML-ification planned only for function arguments?
>> 
>> -Alex
>> 
>> On Wed, Dec 9, 2015 at 12:45 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>> > On Dec 7, 2015, at 8:05 PM, Alex Lew via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >
>> > Hi all,
>> >
>> > Curious to hear thoughts on allowing non-binding pattern matches to be used as boolean values outside of an if, guard, for...in, while, switch, etc. Something like:
>> >
>> > enum List<T> {
>> >      case Empty
>> >      indirect case Link(T, List<T>)
>> >
>> >      func isEmpty() -> Bool {
>> >           return case .Empty = self
>> >      }
>> > }
>> 
>> I agree with you that this is a problem that we should solve, but I think it could be solved in a different way.  Imagine if:
>> 
>> enum Foo {
>>   case X(a : Float), Y, Z(a : Int)
>> }
>> 
>> automatically synthesized these members (the exact names are just a strawman proposal, not serious :-)
>> 
>> extension Foo {
>>   func isX() -> Float? {…}
>>   func isY() -> Bool {…}
>>   func isZ() -> Int? {…}
>> }
>> 
>> This would tie into all of the mechanics we have for dealing with optionals, e.g. if/let and ??
>> 
>> -Chris
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/f8c36536/attachment.html>