Skip to content

Commit f52a0ed

Browse files
committed
doc/ref/spec.md: revert to the old semantics of [k]: v
As it turns out, the old semantics is quite frequently used. Even though it is not hard to simulate the old semantics with the proposed new one, it is still inconvenenient. We do need the more JSON Schema-like semantics, though, as it is hard to simulate with the old semantics. The idea is now to allow `[...K]: V` for pattern constraints to be applied to "additional" fields. So now any constraint that applies to additional fields uses `...`. Another advantage is thats, as we have not yet made the transition to the new semantics, this eliminates a possibly painful transition. Change-Id: Iebd2af03e4929d058e4f3134d77d2071ef3ee82e Reviewed-on: https://cue-review.googlesource.com/c/cue/+/7942 Reviewed-by: Paul Jolly <[email protected]> Reviewed-by: CUE cueckoo <[email protected]>
1 parent 85f8b46 commit f52a0ed

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

doc/ref/spec.md

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1050,8 +1050,13 @@ match that pattern.
10501050
When unifying structs `a` and `b`,
10511051
a pattern constraint `[p]: v` declared in `a`
10521052
defines that the value `v` should unify with any field in the resulting struct `c`
1053-
whose label unifies with pattern `p` and for which there exists no
1054-
field in `a` with the same label.
1053+
whose label unifies with pattern `p`.
1054+
1055+
<!-- TODO: Update grammar and support this.
1056+
A pattern constraints with a pattern preceded by `...` indicates
1057+
the pattern can only matches fields in `b` for which there
1058+
exists no field in `a` with the same label.
1059+
-->
10551060

10561061
Additionally, a _default constraint_, denoted `...value`, defines a value
10571062
to unify with any field for which there is no other declaration in a struct.

0 commit comments

Comments
 (0)