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 <paul@myitcv.org.uk>
Reviewed-by: CUE cueckoo <cueckoo@gmail.com>
diff --git a/doc/ref/spec.md b/doc/ref/spec.md
index e7260a7..4419d03 100644
--- a/doc/ref/spec.md
+++ b/doc/ref/spec.md
@@ -1050,8 +1050,13 @@
When unifying structs `a` and `b`,
a pattern constraint `[p]: v` declared in `a`
defines that the value `v` should unify with any field in the resulting struct `c`
-whose label unifies with pattern `p` and for which there exists no
-field in `a` with the same label.
+whose label unifies with pattern `p`.
+
+<!-- TODO: Update grammar and support this.
+A pattern constraints with a pattern preceded by `...` indicates
+the pattern can only matches fields in `b` for which there
+exists no field in `a` with the same label.
+-->
Additionally, a _default constraint_, denoted `...value`, defines a value
to unify with any field for which there is no other declaration in a struct.
