I agree that this rule would be consistent with the handing of Swift function
signatures, but my proposal is self-consistent and:
1) It is more powerful, matching on the case name or not as required.
2) Is consistent with existing switches that ignore associated values
3) Is constant with ignored labels in other Swift constructs (proposed and in
past versions of Swift, at least)
4) Avoids a possible API change for current enums. This is currently legal but
would not be if the enum case “name” is the entire signature for constructing
it:
```
enum E {
case a( a: Int )
case b( a: Int )
}
let anEmum = E.a( a: 4 )
switch anEmum {
case .a( let x ) :
break
case .b( let x ) :
break
}
switch anEmum {
case .a( let y ) :
break
case .b( let y ) :
break
}
```
So is this proposal worth creating a breaking change? I don’t think so. it
would be possible to ignore the associated parameter name, but not the type,
but that would further confuse case matching, I believe.
I personally don’t see much purpose in having two enum cases with the same name
if they are always treated as distinct and there is no way to reason on the
case name. If they are always distinct, then requiring different names
eliminates unnecessary cognitive load. There is a good reason for functions to
have the same “name” and different signatures, and there are precedents in many
languages.
You may disagree, but I believe that enums exist to support reasoning on
distinct cases and that muddying that by treating the associated value as part
of the “signature" increases the language “surface area” while adding no
tangible benefit.
> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>>
>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
>>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <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
>>> <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
>> <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
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
