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

[David Hart]

Ok, sounds logical. Might be worth adding that info to the proposal to make it clear how ambiguity plays out.

> On 24 Jan 2017, at 13:27, Xiaodi Wu <xiaodi.wu at gmail.com> 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>

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