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

Xiaodi Wu xiaodi.wu at gmail.com
Tue Jan 24 06:27:59 CST 2017


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> wrote:

>
>
> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution <
> 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
> 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/1798bee8/attachment.html>


More information about the swift-evolution mailing list