Great suggestion. Done. > On Jan 24, 2017, at 5:07 AM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 >> <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
