This repository has been archived by the owner on Nov 18, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 170
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc/ref/spec.md: alternative definitions for closedness and friends
This CL changes the meaning of `[x]: y` and `...` fields and closedness with the following objectives: - Incorporate experience of usability of defintions and closedness - Simplify the rules of closedness to simplifiy both its usages and implementation - Make it (far) easier to express JSON Schema in CUE. - Allow closedness to be expressed in terms of CUE itself The expressability of JSON Schema in CUE seems important as this seems to becoming one of the major application domains of CUE. Aside from that, it is a general win for the language as it results in more expressability without loss of generality: the old CUE semantics can easily be simulated by enclosing bulk optional fields in curly braces (the current `cue fmt` and `cue fix` currently do this rewrite). The changes to bulk optional fields (now pattern constraints) bring them in line with the definition of "patternProperties" of JSON Schema. The same holds for the `...` notation, which now maps to additional properties. To allow for a complete one-to-one mapping, the spec now also allows for `...T`. This brings it in line with the semantics for lists. Coincidentally, the new JSON Schema semantics allows closed structs to be defined in terms of CUE itself (using `..._|_`). In addition, the new simplified definition aims to simplify implementation and incorporate user feedback to make definitions and closed structs more intuitive. As a consequence of the simplified defintions, let expressions can no longer be used to circumvent closedness. The relaxed rules around closedness and the earlier reintroduction of hidden fields make this an acceptable compromise. Transition plan: The new definition changes the meaning of existing syntax. The plan is to first rewrite the old semantics into equivalent CUE that will give the same results with the new interpretation. This is already implemented with cue fix and cue fmt. The next step is to prohibit any usage of bulk optional fields that will mean something different with the new syntax (CL pending). Finally, the new behavior is implemented by the new evaluator. Change-Id: I2617597ea4a973d8987239ead4e62d51002c622b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6260 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
- v0.4.0
- v0.4.0-rc.1
- v0.4.0-beta.2
- v0.4.0-beta.1
- v0.4.0-alpha.2
- v0.4.0-alpha.1
- v0.3.2
- v0.3.1
- v0.3.0
- v0.3.0-beta.8
- v0.3.0-beta.7
- v0.3.0-beta.6
- v0.3.0-beta.5
- v0.3.0-beta.4
- v0.3.0-beta.3
- v0.3.0-beta.2
- v0.3.0-beta.1
- v0.3.0-alpha6
- v0.3.0-alpha5
- v0.3.0-alpha4
- v0.3.0-alpha3
- v0.3.0-alpha2
- v0.3.0-alpha1
- v0.2.2
Showing
1 changed file
with
75 additions
and
71 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters