[swift-evolution] [draft] Compound Names For Enum Cases

[Matthew Johnson]

> On Jan 23, 2017, at 6:03 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Jan 23, 2017, at 4:00 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> 
>>> On Jan 23, 2017, at 5:52 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 
>>>> 
>>>> On Jan 23, 2017, at 3:49 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.
> 
> Independent of that feature, laying out enums so that similar-shaped parts of each payload overlap is a good general layout optimization, so that the payload can be retain/released on copy with no or minimal switching over the tag first.

Ok, so the most important part is giving the compiler the ability to optimize the layout.  Additional features will take advantage of the optimization, but not drive the design of the layout.  Is that correct?

> 
> -Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170123/85bf8472/attachment.html>