Your example is only has only one case, which is not typical. Perhaps I am
missing something, but the only reason that I can imagine for having a case
with multiple ways to “construct” it is to have all variants of the case to
match. If you don’t want them to match, use a different case name.
It would still be possible to match on the different types of bar when needed:
```
enum Foo {
case bar(a: Int)
case bar(b: String)
case notAbar
}
switch aFoo {
case .bar( let a: Int) : // matches Ints only
...
case .bar( let b: String) : // matches Strings only
...
}
switch aFoo {
case .bar : // Matches both cases and that is a good thing
…
case notAbar:
….
}
```
> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
> I would imagine it would be logical to have it work just like it does now
> with functions. If case bar is distinct, then that should still work, but if
> bar is "overloaded," then case bar should be invalid for ambiguity. Seems
> fine to me, shouldn't break any existing code and therefore we don't lose
> anything.
>
>
> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>
> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> We're not terribly principled about this right now with non-pattern
>> declaration references. You can still reference an unapplied function by its
>> base name alone without its labels, if it's unambiguous:
>>
>> func foo(x: Int, y: Int) {}
>>
>> let foo_x_y: (Int, Int) -> () = foo
>>
>> so it'd be consistent to continue to allow the same in pattern references.
>
> WRT ambiguity, do we loose the ability to pattern match on the naked case
> name when two cases share the same base name?
>
> enum Foo {
> case bar(a: Int)
> case bar(b: String)
> }
>
> switch aFoo {
> case .bar: // matches both cases
> break
> }
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <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
