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...@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@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 https://lists.swift.org/mailman/listinfo/swift-evolution
