Automatically derive properties for enum cases

[stephencelis]

Yep, @anandabits has explored this a bit and may have more to comment. Seems that such a future would still be compatible with this synthesis, and seems that this synthesis is still required for key path support.

[anandabits (Matthew Johnson)]

Agreed. Enum case types and subtyping falls into the broad category of enum ergonomics but is orthogonal to property synthesis.

I wrote up a lot of ideas on value subtyping and enum ergonomics while ago. Anyone interested can find the gist here: ValueSubtypeManifesto.md · GitHub. If anyone is interested in collaborating on implementation of any of these ideas I would be more than happy to help with design and proposal drafting. That said, let's keep this thread focused on property synthesis.

[ethanjdiamond (Ethan Diamond)]

@anandabits

interested can find the gist here: ValueSubtypeManifesto.md · GitHub

Thanks @stephencelis + @anandabits. I like the direction that points and would definitely support it.

[duan (Daniel Duan)]

I'm very much in favor of tackling the issues of enum + key paths and enum ergonomics.

In the acceptance of SE-0111, core team envisioned a future proposal to "restore the expressive capability of closures with parameter labels". It was a two-step process, the first of which is relevant to this discussion:

First, we extend declaration names for variables, properties, and parameters to allow parameter names as part of their declaration name. For example:

var op(lhs:,rhs:) : (Int, Int) -> Int // variable or property.
x = op(lhs: 1, rhs: 2) // use of the variable or property.

// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
func foo(opToUse op(lhs:,rhs:) : (Int, Int) -> Int) {
  x = op(lhs: 1, rhs: 2) // use of the parameter
}
foo(opToUse: +) // call of the function

SE-0155 was brought forth partially to align case names to this future (although it might not have been explicitly stated), where names, for variables, cases or functions alike, includes labels.

Admittedly, some time has passed since this core team commentary, the community has evolved and may have made discoveries that invalidate these old goals. Heck, one might say the same about SE-0155.

Personally however, I'm still hoping the stuff in the commentary will happen one day. And I think it's not a insurmountable task to implement in the compiler (unlike SE-0155)

I'm curious to see what are y'alls thoughts on the commentary in conjunction of what's being proposed here:

1. Is the future vision in the commentary worth preserving?
2. If so, how should this proposal accommodate for it?

(I apologies in advance if this post de-focuses the discussion, we should start a separate thread at first sign of this happening!)

[Anders_Ha]

@Tino

I haven’t seen any representative studies on how many people actually use enums that would benefit from those derived properties, but I don’t think they are that useful for error-handling, which imho is what most enums out there are used for (and especially in this context, the change might even be harmful if you can’t opt-out).

Swift's enumeration is an especially useful instrument for modelling mutually exclusive states/scenarios as a finite state machine. This pitch does make working with these enums easier by saving all those switch statements to extract the payloads of a particular case, speaking from my experience of utilising enums as FSM models widely in a production codebase.

It is also quite a breeze to work with if combined with FRP to implement unidirectional data flows (e.g. ReactiveFeedback and RxFeedback). But even if we ignore its application within the FRP realm, one could still enjoy the mutual exclusivity between groups of associated values enforced by the compiler.

Meanwhile, the alternative would be having a sea of ad hoc properties, potentially optional, relying entirely on the programmer and code comments to predicate over the correct combinations. But we have the tool with the first class compiler support, so why shouldn't we strive for the better?

[Tino]

@Anders_Ha

Meanwhile, the alternative would be having a sea of ad hoc properties, potentially optional, relying entirely on the programmer and code comments to predicate over the correct combinations.

So it's better to have a sea of properties that are created no matter wether you need them or not? Which would interfere with properties that developers created because they are actually required for their code? Which need rules for all kinds of edge cases right in the compiler?
Don't understand me wrong, I already wrote that it's fine for me if people use the the techniques outlined in this thread - I just don't think it's good to put all of this into the compiler.

Taking you example of FSM: Do you have numbers how many Swift projects use an explicit state machine, how many of those don't use enums to model their state at all, and how big the number of project that use enums for error handling is in comparison?

Besides that:
If someone is really serious about FSM, the first thing he creates is probably a tool for visualization, or even a custom DSL - so creating code for the states is only a small extra step.

[Tino]

@Anders_Ha

But we have the tool with the first class compiler support, so why shouldn’t we strive for the better?

Afaik, we don't have anything (regarding this pitch) - it would have to be build.

Even if deriving those properties would be configurable, so that they don't disturb people who don't need them, it's another piece of logic that has to fit into the rest.
Swift already is quite a complex language, but still, the first thing when we encounter a tiny bit of inconvenience is yelling for special compiler magic, instead of striving for solutions that are more universal, powerful and most likely more simple as the sum of all special cases.