tree 3b7be02758f63326d326ce385ad919e2fc41dc97
parent 6c27cef9ec2b6d5bb46f0bfd5c09dfba84536942
author Marcel van Lohuizen <mpvl@golang.org> 1595685645 +0200
committer Marcel van Lohuizen <mpvl@golang.org> 1599751673 +0000

doc/ref/spec: consider definitions for closedness

Definitions were excempted from closedness checks.

With this change, it can be guaranteed that if a template
writer does not make an existing field more specific
and a user doesn't embed the template, the changes
cannot break a user.

Consider this template:
	-- pkg.com/foo/foo.cue --
	#Def: {}

And its usage:

	-- bar.cue --
	import "pkg.com/foo/foo.cue"

	def: #Def & {
	  #foo: 2
	}

The introduction of #foo is currently allowed, as
closedness is not checked for definitions. So
if the original template is no augmented as such

	-- pkg.com/foo/foo.cue --
	#Def: {
	  #foo: 1
	}

it breaks the user.

This means though, that it breaks the property that if
a template writer changes their template, it may
conflict with a definition that a user may have added.

This already holds for regular fields, but that is to be
expected. Users can still add definitions by embedding
the struct. But the same warning applies in this case
for regular fields and definitions, making it more
consistent.

Breakage can also occur if a template writer makes a
template more specific. Again here also, this also holds
for regular fields and this also makes definitions more
consistent with regular fields.

Change-Id: I1e2aedcf6cc4b17f17f9b4a742ca7aac238ae382
Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6721
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>