Extract Payload for enum cases having associated value

[gwendal.roue (Gwendal Roué)]

@ExFalsoQuodlibet

enum Foo {
  case bar(Int)
}

[...]

The .bar in let doesntCompile: Foo = .bar won't compile because we need an expression that evaluates to "something" there. Taken as an expression, .bar should be a (Int) -> Foo function, but it's not defined on the (Int) -> Foo type, in fact:

let stillDoesntCompile: (Int) -> Foo = .bar

causes the compilation error type '(Int) -> Foo' has no member 'bar' , because .bar is defined on the type Foo . There's no way out here.

I want to have a less direct conclusion, and expose some its intermediate steps.

The code below can't compile, because nothing says that the .bar "thing" has to come from Foo:

let myCase = .bar // WAT?
enum[case: myCase]

What can we change to make it compile?

What about an explicit type information, which would help type inference? The code below doesn't compile today, but it could be made valid in a future compiler version. All the required information is there:

let myCase: (Int) -> Foo = .bar // Could be made to compile one day.
enum[case: myCase]

The type (Int) -> Foo is the only possible type that we can put at this place today, as long as .bar, an Implicit Member Expression remains defined as:

An "implicit member expression" is an abbreviated way to access a member of a type, such as an enumeration case or a type method, in a context where type inference can determine the implied type.

(Emphasis mine). The only known member named bar that we know is Foo.bar, typed (Int) -> Foo. It is the only one we currently have.

Can we invent a new bar member somewhere else? Yes we can, many above have tried, with the synthesis of various derived types from the base enum (see messages above). But those are other pitches.

So, (Int) -> Foo. And now we have a real problem. It has already been stated above, I don't invent it. The real problem is that (Int) -> Foo falls short in terms of type-safety. Would the [case:] subscript accepts any such function, and not only cases from the Foo enum, the proposal would sound too dangerous for many.

So... I think the the suit is too tightly cut. We don't have enough freedom. We actually can't really "make it compile somehow", because we face contradictions or undesired side effects.