[swift-evolution] Proposal: pattern match based on associated value(s) only

[Amir Michail]

> On Feb 26, 2016, at 12:25 AM, Andrew Bennett <cacoyi at gmail.com> wrote:
> 
> Hi Amir,
> 
> I put forward a proposal a short while ago that may allow you to achieve similar to what you want, it is here:
> 
> Declare variables in 'case' labels with multiple patterns
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007431.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007431.html>
> 
> https://github.com/apple/swift-evolution/pull/119 <https://github.com/apple/swift-evolution/pull/119>
> 
> It would allow you to express your logic like this:
> 
>   switch vehicle {
>   case .Car(let color), .Motorcycle(let color), .Helicopter(let color):
>       switch color {
>       case .Red:   ...
>       case .Green: ...
>       case .Blue:  ...
>       }
>   }
> 
> That proposal seemed to be well received with no votes against, and after a few tweaks seemed to have support from the Swift team.
> 
> What do you think about that approach? It's not quite as concise as what you proposed but it can be generalised more easily, and handles pattern matching of cases where `color` may not be the only associated value.
> 

I like both proposals, yours and mine. They both have their uses.

> 
> On Wed, Feb 24, 2016 at 1:13 AM, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Feb 23, 2016, at 7:27 AM, Taras Zakharko <taras.zakharko at uzh.ch <mailto:taras.zakharko at uzh.ch>> wrote:
>> 
>> I think that other designs (e.g. using classes/structs/protocols) offer a much better solution for this particular problem
>> 
> 
> That might be more work than just listing all the cases...
> 
>>> On 23 Feb 2016, at 13:17, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> 
>>>> On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>>> 
>>>>> For example:
>>>>> 
>>>>> enum Color {
>>>>> 	...
>>>>> }
>>>>> 
>>>>> enum Vehicle {
>>>>> 	case Car(Color)
>>>>> 	case Motorcycle(Color)
>>>>> 	...
>>>>> }
>>>>> 
>>>>> switch vehicle {
>>>>> 	case _(.Red): … // pattern match based on associated value only
>>>>> }
>>>> 
>>>> As usual, Amir: 
>>>> 
>>>> 1. Why do you want this feature?
>>> 
>>> In this example, if there are many kinds of vehicles, it would be annoying to have to write a case for each one to match associated value .Red.
>>> 
>>>> 
>>>> 2. What's actually wrong with the status quo?
>>>> 
>>> 
>>> What would that be for this example? Many cases?
>>> 
>>>> 3. Can you talk about a non-toy example you've encountered where it would have made your code better?
>>>> 
>>>> 4. Can you talk about the proposed design in a little more detail? Are there weird edge cases, and how would you handle them? (In the case of this feature, here's one I see: Suppose you have two different associated value types but they both have a .Red case. What happens then?)
>>>> 
>>>> A half-dozen-word subject line and a code example simply aren't enough to evaluate a proposal. Without knowing exactly what you're proposing and why you think it's a good idea, we can't really evaluate it properly.
>>>> 
>>>> -- 
>>>> Brent Royal-Gordon
>>>> Architechies
>>>> 
>>> 
>>> _______________________________________________
>>> 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>
> 
> 
> _______________________________________________
> 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/20160226/0e8b0051/attachment.html>