[swift-evolution] [draft] Compound Names For Enum Cases

Matthew Johnson matthew at anandabits.com
Tue Jan 24 15:23:53 CST 2017


> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution <swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/2be2fba2/attachment.html>


More information about the swift-evolution mailing list