> On Jan 23, 2017, at 5:52 PM, Joe Groff <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. :)
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
