Support some, ok and err wrappers and untyped function inputs
This commit is contained in:
1 parent
6e4f9cd65a
commit
79533e9537
20 files changed
+36187
-35406
No files matched your search
+27
-7
@@ -43,13 +43,33 @@ Literal leaves are named. Boolean and nil values use `boolean_literal` and
|
||||
`nil_literal`; numeric, string, character, and unit literals retain their
|
||||
specific nodes. `default_expression` is also named.
|
||||
|
||||
`function_literal` takes one input and owns the `body` field. Direct binding
|
||||
appears as `parameter: (typed_parameter)`; tuple destructuring appears as
|
||||
`parameter: (typed_tuple_pattern)`. A `typed_tuple_pattern` contains zero or at
|
||||
least two `typed_tuple_component` nodes. These bind components of one tuple
|
||||
input, not separate function arguments. `()` matches unit; singleton tuple
|
||||
patterns are invalid. Typed bindings expose `pattern` and `type`; a header may
|
||||
also expose `effect` (`->` or `=>`) and `result`.
|
||||
`some`, `ok`, and `err` construct optional and result values. They are prefix
|
||||
operators, so `some value` and `ok {x->f}` appear as `unary_expression` nodes
|
||||
whose `operator` is the keyword. They bind like `-` and `~`, so `ok x->f`
|
||||
wraps `x` and then pipes the result into `f`, while `ok {x->f}` wraps the
|
||||
pipeline. The older `|.some`/`|.ok`/`|.err`
|
||||
constructors, postfix `value!`, and prefix `!error` are no longer accepted.
|
||||
|
||||
`function_literal` takes one input and owns the `body` field. A pattern with
|
||||
one annotation for the whole input, such as `@ value: i32` or
|
||||
`@ (left, right): (i32, i32)`, appears as `parameter: (typed_parameter)`.
|
||||
The annotation is optional: an input whose type comes from the expected
|
||||
function type, such as `@ value` or `@ (left, right)`, is also a
|
||||
`typed_parameter` without a `type` field. Component-annotated tuple
|
||||
destructuring, such as `@ (left: i32, right)`, appears as
|
||||
`parameter: (typed_tuple_pattern)`. A `typed_tuple_pattern` contains at least
|
||||
two `typed_tuple_component` nodes, each with an optional `type`. These bind
|
||||
components of one tuple input, not separate function arguments. `()` matches
|
||||
unit and is a `typed_parameter` over a `unit_pattern`; singleton tuple patterns
|
||||
are invalid. Bindings expose `pattern` and, when annotated, `type`; a header
|
||||
may also expose `effect` (`->` or `=>`) and `result`.
|
||||
|
||||
## Patterns
|
||||
|
||||
`wrapper_pattern` matches `some`, `ok`, or `err` applied to one pattern atom.
|
||||
It exposes `wrapper` (the keyword) and `value` (the inner pattern). `nil` is
|
||||
still a `nil_literal` pattern. Sum patterns retain `sum_pattern` with a
|
||||
`variant` field.
|
||||
|
||||
## Types
|
||||
|
||||
|
||||
Reference in new issue
Block a user