Type spreads of regular variants in patterns

[zth]

Solves part of #6273
Closes #6562
Closes #6277

This PoC adds support for type spreads of regular variants in patterns. This is already a thing with polyvariants, and now it's also a thing for regular variants.

Rationale is we already have variant spreads and coercion, which lets you go from small type to big type. Having this will let you go from big type to small type. This is a missing piece.

Specification:

• Any variant X that is a subtype of variant Y can be spread in a pattern matching of a value of type Y
• Using an alias ...subtypeVariant as value will give the type subTypeVariant to value
• Syntax: Spreads of regular variants are done like spreads of polyvariants, but without the leading #: | ...subtypeVariant as value => doSomethingWithSubTypeVariant(value)

type a = One | Two | Three
type b = | ...a | Four | Five

let doWithA = (a: a) => {
  switch a {
  | One => Js.log("aaa")
  | Two => Js.log("twwwoooo")
  | Three => Js.log("threeeee")
  }
}

let lookup = (b: b) =>
  switch b {
  | ...a as a => doWithA(a)
  | Four => Js.log("four")
  | Five => Js.log("five")
  }

Should be a well isolated feature, since it's dependent on the parser adding an attribute when the spread is a regular variant (no leading #) and no regular pre-existing code path is touched.

[zth]

@cristianoc did you see this here? That we're not caring about type params. Type params aren't allowed in spreads anyway right now so maybe it doesn't matter.

[cristianoc]

Maybe worth checking that there are no type params, so it's not overlooked in future.

[glennsl]

A couple issues I've found:

1. The variant spread pattern does not nest:

let lookup = (b: option<b>) =>
  switch b {
  | Some(...a as a) => doWithA(a)
  | Some(Four) => Js.log("four")
  | Some(Five) => Js.log("five")
  | None => Js.log("None")
  }

yields the syntax error:

  35 │ let lookup = (b: option<b>) =>
  36 │   switch b {
  37 │   | Some(...a as a) => doWithA(a)
  38 │   | Some(Four) => Js.log("four")
  39 │   | Some(Five) => Js.log("five")

  Did you forget a `)` here?

2. Not directly related to this PR but to variant spread as a whole, the subtype relationship does not nest either.

let f = (x: array<a>) => (x :> array<b>)

  33 │   }
  34 │ 
  35 │ let f = (x: array<a>) => (x :> array<b>)
  36 │ 

  Type array<a> is not a subtype of array<b> 
  Type a is not compatible with type b 

This error message is clearly incorrect, and the workaround requires an unnecessary map:

let f = (x: array<a>) => x->Array.map(a => (a :> b))

Edit: Coercing arrays don''t seem to work in general. Coercing options do though.

[zth]

@glennsl could you check:

1. Whether the same holds for polyvariant spreads
2. Whether the same holds for a non spread variant, so the spread variant but written out manually

[tsnobip]

Could be missing the same kind of thing in the parser that was missing for dict parsing.

[glennsl]

@glennsl could you check:

1. Whether the same holds for polyvariant spreads

2. Whether the same holds for a non spread variant, so the spread variant but written out manually

Nested polyvariant spread patterns work. Writing the variants out manually does not. That is, Some((One | Two | Three) as a) is syntactically valid, but does not infer a to be of type a.

[glennsl]

Also, coercing arrays does not work for polyvariants either. Apparently it doesn't work for arrays at all, maybe it's a variance issue. options work in both cases though. So scratch that.

[zth]

Could be missing the same kind of thing in the parser that was missing for dict parsing.

Ah yes, nice catch! It seems to be at least partly the same, forgot about is_pattern_start.

[zth]

@glennsl got it thanks. Yeah, arrays is because of variance. We did do a sort of fix for that at some point: #6518