> On Jan 23, 2017, at 3:49 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > > On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> This looks pretty good! It might be worth calling out explicitly that >> matching a payloaded case by name alone still works, e.g.: >> >> enum Foo { case foo(Int), bar(x: Int) } >> >> switch Foo.foo(0) { >> case .foo: >> break >> case .bar(x:): >> break >> } > > In your example would 'bar(x:)' be required or would a naked 'bar' also be > valid? I'm guessing it would not be valid which strikes me as slightly > unfortunate. This would create some unpleasant verbosity in some places that > isn't required today. (Incidentally, a nontrivial amount of this code would > be in easily derivable "isSameCase" equivalence relations that compare the > case used but not the associated values)
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. > > Another question - if labels become part of the case name does that mean we > can "overload" the base name? > > enum Foo { > case bar(x: Int) > case bar(y: Int) > } > > The example is intentionally problematic because I'm not sure this would be a > good idea, but more realistic examples may be possible with cases more > meaningfully distinguished by associated value labels. > > This is an idea that naturally follows with a move to a more function-like > model of enum cases with labels being part of the name so it's worth > discussing whether or not it should be allowed. Yeah, if labels really are part of the decl name then this isn't an "overload" at all, so we should allow it. -Joe
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution