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

[Andrew Bennett]

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> 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
>>
>> Untracked with Trackbuster <https://trackbuster.com/?sig>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/5b4f3a13/attachment.html>