Automatically derive properties for enum cases

Evolution Pitches
124

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!)

4 Likes