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

plx plxswift at icloud.com
Thu Dec 10 09:24:30 CST 2015


FWIW, as long as we’re asking for some compiler assistance generating useful enumeration-related boilerplate, I’d like to request that something along these lines be possible in some version of Swift:

@synthesize_case_enum
enum Example {

  case Foo(X)
  case Bar
  case Baz(Y)

}

…which would then by default expand to something like this:

enum ExampleCase : Int {
  
  case Foo
  case Bar
  case Baz

}

extension Example {
 
  var enumerationCase: ExampleCase {
    get {
      switch self {
        case .Foo(_): return .Foo
        case .Bar(_): return .Bar
        case .Baz(_): return .Baz
      }
    }
  }  

}

…in the default case, but with some customization of the synthesized enumeration-case-enum’s details.

For the remaining proposals:

- `isX()` is nice (and should always `-> Bool`, IMHO)
- `projectX()` is nice and should:
  - *not* be defined for enums w/out associated values
  - `-> T?` for enums w/ a single associated value
  - -> the full tuple, for enums w/ multiple associated values, e.g.:
    - `Foo(A,B)` yields `projectFoo() -> (A,B)?
    - `Event(place: Place, time: Time)` -> (place: Place, time: Time)?
    - (which is essentially the same as for the single-value case, just making it explicit)

…which has the benefit of predictability (and if you need more convenience, replace your tuples with actual classes-or-structs). 

Finally, as convenient as the `associatedValue` proposal is down below, it seems better-served by some sort of generalized delegation construct; at a minimum, I don’t think it's that uncommon to have N cases all wrapping the same underlying type, and in such cases working with an `Any?` would feel rather clunky.

> On Dec 9, 2015, at 3:00 PM, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I really like this solution and perhaps you can also go @projectable("empyValue") if the default name is a bad choice. See @obc for similar usage.
> 
> On Thursday, 10 December 2015, Alex Lew via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Semantically, I believe enums with more than one associated value are actually just enums with one associated value, of tuple type.
> 
> I'm not convinced it would be bad to do magic function generation, but it's worth considering explicit syntax. If we were to use @ compile-time attributes, maybe it could be a word before the case -- like @projectable or @selectable (or some better name)?
> 
> enum List<T> {
>      @projectable case Empty
>      indirect case FirstAndRest(T, List<T>)
> }
> 
> generates:
> myList.isEmpty() -> Bool
> 
> Another option: some sort of @reflectable attribute on the enum itself.
> 
> @reflectable enum Pet {
>      case Cat(name: String, color: String)
>      case Dog(name: String, breed: String)
>      case Bear(name: String, isHibernating: Bool)
> }
> 
> And one other option, in a very different direction, that seems weird but maybe has its benefits:
> 
> What if we exposed an associatedValue computed property of type Any? (It would be unit type for cases with no associated value.)
> 
> You could then do something like this:
> 
> enum Contact {
>      case Person(String) // name
>      case Business(String) // org name
>      case FamilyMember(String) // relation name
>      case RecentCall(Int) // a contact from caller id, only store the phone number
> 
>      func name() -> String {
>           return associatedValue as? String ?? "Unknown (\(associatedValue as! Int))"
>      }
> }
> 
> Essentially, it allows you to project out a relatively common associated value (in this case a string) without much boilerplate. It's also just one thing for the compiler to generate, instead of n. Not crazy about any of these... just brainstorming. It may also be that a concise switch-like control flow expression eliminates the need for this.
> 
> -Alex
> 
> On Wed, Dec 9, 2015 at 11:49 AM, thorsten at portableinnovations.de <javascript:_e(%7B%7D,'cvml','thorsten at portableinnovations.de');> <thorsten at portableinnovations.de <javascript:_e(%7B%7D,'cvml','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).
> 
> As to naming I like the proposal #1 by Alex.
> 
> What about enums with more than one associated value?
> 
> -Thorsten
> 
> Am 09.12.2015 um 07:29 schrieb Alex Lew via swift-evolution < swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','clattner at apple.com');>> wrote: 
>> 
>> > On Dec 7, 2015, at 8:05 PM, Alex Lew via swift-evolution <swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution> 
> Untracked with Trackbuster <https://trackbuster.com/?sig>
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/109c0260/attachment.html>


More information about the swift-evolution mailing list