This makes the following parse
# assuming
Opaque : Opaque Int
{ x: (Opaque y) } = foo
In most cases a pattern of this kind will not be exhaustive, but it
should be syntactically valid.
Couple of things
- conversion of the value (in `key: value`) requires converting from
expr into a pattern, which returns a `Result` which now propagates. A
comment notes though that the cases for which it gives Err should not
parse. so, is the Result useful here?
- AssignedField constructors have a field for spaces, but also a
SpacesAfter constructor. Are they different? it seems like the spaces
field could be removed in favor of using SpacesAfter.
there are a couple of cases here that are interesting:
- assigned fields, like `{ x: y }` should never occur as a pattern.
- what whitespace can occur now that block comments are removed? In elm, record patters have to be on a single line. For instance this gives a parse error:
```elm
type alias Model =
{ count : Int, value : Int }
x model =
case model of
{ count
-- bar
, value
}
->
2
```
but its equivalent in Roc with the current parser accepts both newlines and
line comments in record patterns, so this is accepted:
```
x model =
case model with
{ count
# bar
, value
}
->
2
```
That seems fine, but just want to
check that is desired.
a couple of open questions:
- shouldn't patterns (for formatting) make the distinction between block
and line?
- can the `arena.alloc` be removed? the Vec is already allocated by bumpalo
- for error reporting, is it better to distinguish block and line?
This may break annotation parsing. (I'm not sure; there are no annotation
parsing tests yet.) Something fishy is happening with the one_of2 in def().
If I remove the one_of2, then defs parse correctly. If I reverse the
order of one_of2's arguments, they also pass. This suggests the first
argument to one_of2 (the "parse type alias or custom type") logic was
passing...but on further investigation, it appears that is actually
failing. (Meaning it shouldn't affect one_of2!)
Needs further investigation when I get back to annotations, but for now,
this fixes the problem and leaves the code in a reasonable place.
