> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution
> <[email protected]> wrote:
>
> 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 sounds like you are missing something. The `bar(a:)` and `bar(b:)` are the
full case names. These are *not* the same case. The `bar` shorthand is
allowed when there is no ambiguity, however for an enum with both `bar(a:)` and
`bar(b:)` there *is* ambiguity and therefore the `bar` shorthand is not
allowed. The programmer is required to spell out the full name of the case
they wish to match.
>
> 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] <mailto:[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] <mailto:[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
