This would be a real loss 😔. Another nice thing we would be losing is tuple
field labels *after* matching:
if case let .bar(a) = Foo.bar(x: Int, y: Int) {
doThings(with: a.x, a.y)
}
Keeping them means we have the create a special (reverse)splatting rule for
pattern matching. I can see a few arguments against this:
1. It's a cost in complexity that pays for some niche convenience (or not?
Real-world usage research needed)
2. It can be added later without introducing source-breakage (but keeping it
means less source-breakage after this proposal, again, depends on usage in the
wild).
3. Depends on whether splatting comes up in the future, we may want to relate
the syntax here and there.
4. As Tony mentioned, auto-deriving equitable could lead to eventual glory.
I was convinced to keep the feature after reading your example but now I'm not
sure again. Grrrr.
> On Jan 22, 2017, at 7:42 AM, T.J. Usiyan <[email protected]> wrote:
>
> Implementing equality would be made tedious again if we lose this.
>
> ```
> enum Jams : Equatable {
>
> case dmsr(Bool)
> case kiss(Bool, Bool)
> case pheromone(Int, Bool, Int)
>
>
> public static func ==(lhs:Jams, rhs:Jams) -> Bool {
> switch (lhs, rhs) {
> case let (.dmsr(left), .dmsr(right)):
> return left == right
> case let (.kiss(left), .kiss(right)):
> return left == right
> case let (.pheromone(left), .pheromone(right)):
> return left == right
> case (.dmsr, _), (.kiss, _), (.pheromone, _):
> return false
> }
> }
> }
> ```
>
>
>
>> On Sun, Jan 22, 2017 at 4:51 AM, Robert Widmann via swift-evolution
>> <[email protected]> wrote:
>> Sure. One of the first gadgets I wrote was a way of destructuring an array
>> into a familiar cons-list kind of enum
>> (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9) which
>> you use something like this with other non-trivial enums
>> (https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161).
>>
>> It's not strictly a problem for me to lose this feature, but it is gonna be
>> a bit weird if we lose recursive match but also allow it for just plain old
>> tuple patterns.
>>
>> ~Robert Widmann
>>
>> 2017/01/22 3:02、Daniel Duan <[email protected]> のメッセージ:
>>
>>> FWIW, in all public Github repos with 5k+ stars whose language gets
>>> recognized as “Swift”, 576 enum cases has associated values and among them
>>> 55 has 2 values or more. After some very casual grepping I didn’t find a
>>> lot of usage of this particular pattern.
>>>
>>> Care to share some examples, Robert?
>>>
>>> - Daniel Duan
>>>
>>>> On Jan 21, 2017, at 11:00 PM, Robert Widmann <[email protected]>
>>>> wrote:
>>>>
>>>> I find myself doing this a lot, but maybe my problems are just more
>>>> Algebra-shaped than most. That said, I appreciate this cleanup and lean
>>>> +1 (because you mentioned a way to partly keep this behavior).
>>>>
>>>> ~Robert Widmann
>>>>
>>>> 2017/01/19 18:14、Joe Groff via swift-evolution <[email protected]>
>>>> のメッセージ:
>>>>
>>>>>
>>>>>> On Jan 19, 2017, at 2:58 PM, Daniel Duan <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>>> On Jan 19, 2017, at 2:29 PM, Joe Groff <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>> This looks totally reasonable to me. A couple of comments:
>>>>>>>>
>>>>>>>> 1) Because this proposal is breaking the link between the associated
>>>>>>>> value of an enum case and tuple types, I think it should spell out the
>>>>>>>> rules that switch statements will use when matching an enum value
>>>>>>>> against a a case with an associated value. Some kind of rules fell out
>>>>>>>> of them being treated as tuple types, but they might not be what we
>>>>>>>> want.
>>>>>>>
>>>>>>> I was about to bring up the same. Right now, an enum pattern works like
>>>>>>> .<identifier> <tuple-pattern>, where the <tuple-pattern> then
>>>>>>> recursively matches the payload tuple. In this model, it seems like
>>>>>>> we'd want to treat it more like .<identifier>(<pattern>, <pattern>,
>>>>>>> ...). Similar to how we lost "tuple splatting" to forward a bunch of
>>>>>>> arguments, we'd have to decide whether we lose the ability to match all
>>>>>>> parts of the payload into a tuple.
>>>>>>
>>>>>> I’m leaning towards “no” for simplicity of the language (and
>>>>>> implementation). That means this would be source-breaking 😞. Will
>>>>>> update the proposal and see how the rest of the feedback goes.
>>>>>
>>>>> It'd be a good idea to try to find examples of people doing this out in
>>>>> the wild too, to see how widespread it is as well as how onerous the
>>>>> workarounds for losing the feature would be.
>>>>>
>>>>> -Joe
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
