> 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
