Proposal: pattern match based on associated value(s) only

Amir_Michail1 · 2016-02-23T02:30:19.000Z

For example:

enum Color {
...
}

enum Vehicle {
  case Car(Color)
  case Motorcycle(Color)
  ...
}

switch vehicle {
case _(.Red): … // pattern match based on associated value only
}

Brent_Royal-Gordon · 2016-02-23T03:11:32.000Z

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?

2. What's actually wrong with the status quo?

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

Amir_Michail1 · 2016-02-23T12:17:36.000Z

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?

···

On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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

sethfri · 2016-02-28T21:39:46.000Z

+1 to this. I've said this before, Amir, but please take the time to
actually write a considered proposal instead of increasing the already high
traffic of this list with a couple words and a code sample.

···

On Mon, Feb 22, 2016 at 7:11 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> 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?

2. What's actually wrong with the status quo?

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Taras_Zakharko1 · 2016-02-23T12:22:54.000Z

I think that other designs (e.g. using classes/structs/protocols) offer a much better solution for this particular problem

···

On 23 Feb 2016, at 13:17, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Taras_Zakharko1 · 2016-02-23T12:27:23.000Z

I think that other designs (e.g. using classes/structs/protocols) offer a much better solution for this particular problem

···

On 23 Feb 2016, at 13:17, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Andrey_Tarantsov · 2016-03-02T07:00:25.000Z

And regarding:

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?

A non-toy example is something that's likely to be found in a real app.

A.

Amir_Michail1 · 2016-02-23T14:13:59.000Z

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 Feb 23, 2016, at 7:27 AM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

On 23 Feb 2016, at 13:17, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Andrew · 2016-02-26T05:25:11.000Z

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

github.com/apple/swift-evolution

Variables in case labels with multiple patterns

apple:master ← therealbnut:therealbnut-case-match

opened 05:03AM - 24 Jan 16 UTC

therealbnut

+190 -0

Proposal to "Declare variables in 'case' labels with multiple patterns". Thanks… for your time [0023-declare-variables-in-case-labels-with-multiple-patterns.md](https://github.com/therealbnut/swift-evolution/blob/therealbnut-case-match/proposals/0023-declare-variables-in-case-labels-with-multiple-patterns.md)

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.

···

On Wed, Feb 24, 2016 at 1:13 AM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

On Feb 23, 2016, at 7:27 AM, Taras Zakharko <taras.zakharko@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@swift.org> wrote:

On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Amir_Michail1 · 2016-02-26T12:23:38.000Z

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
[swift-evolution] Draft Proposal: Declare variables in 'case' labels with multiple patterns

Variables in case labels with multiple patterns by therealbnut · Pull Request #119 · apple/swift-evolution · GitHub

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 Feb 26, 2016, at 12:25 AM, Andrew Bennett <cacoyi@gmail.com> wrote:

On Wed, Feb 24, 2016 at 1:13 AM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 23, 2016, at 7:27 AM, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 22, 2016, at 10:11 PM, Brent Royal-Gordon <brent@architechies.com <mailto:brent@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution