> On Jan 23, 2017, at 4:00 PM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Jan 23, 2017, at 5:52 PM, Joe Groff <jgr...@apple.com >> <mailto:jgr...@apple.com>> wrote: >> >>> >>> On Jan 23, 2017, at 3:49 PM, Matthew Johnson <matt...@anandabits.com >>> <mailto: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. > > Ok, if we follow this behavior then I am very much +1 on this direction. > >> >>> >>> 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. > > Yeah, that’s why I put “overload” in quotes. :)
Added text in the proposal to clarify this point. Thanks, y’all! > > If this proposal is accepted the compiler will have more flexibility for > layout of enums with associated values. Are there any other enum-related > features that could impact the layout used (and therefore should be > considered before ABI is locked down)? > > For example, I’m thinking of the topic that seems to pop up fairly often > related to enums that have several (or possibly all) cases sharing an > associated value name and type, which are often viewed as conceptually > similar to properties in the discussions that have happened. > >> >> -Joe
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
