evalv3: close({...}) does not allow fields

[rogpeppe]

What version of CUE are you using (cue version)?

82995bbb8e3725c40806fdec426452d76b284eeb

Does this issue reproduce with the latest stable release?

Yes (v0.10.0)

What did you do?

exec cue vet x.cue

env CUE_EXPERIMENT=evalv3
exec cue vet x.cue

-- x.cue --
close({...}) & {x: 1}

What did you expect to see?

Passing test. Closing a struct with an ellipsis should not disallow fields in that struct.

What did you see instead?

> exec cue vet x.cue
> env CUE_EXPERIMENT=evalv3
> exec cue vet x.cue
[stderr]
x: field not allowed:
    ./x.cue:1:1
    ./x.cue:1:17
[exit status 1]
FAIL: /tmp/x.txtar:4: unexpected command failure

[mvdan]

Is this because of the following line in the spec?

A struct that is the result of unifying any struct with a ... declaration is defined for all regular fields.

Perhaps we should add an example to the spec, because I wasn't aware of this quirk.

[rogpeppe]

Is this because of the following line in the spec?

A struct that is the result of unifying any struct with a ... declaration is defined for all regular fields.

That sentence seems somewhat misleading to me FWIW.
For example:

#a: {...}
#b: {a?: int}
#c: #a & #b
#c: b: 2

The above example gives an error even though #c is "the result of unifying any struct with a ... declaration" AFAICS, and that seems like correct behaviour to me.

Note that if closing really did close up ... fields, then ellipses would be essentially useless because a definition would also close (recursively) any ellipses within the definition so, for example:

#a: {
    ...
}

would not allow any fields.

Perhaps we should add an example to the spec, because I wasn't aware of this quirk.

The spec could definitely use improvement in this area.
For example, it says:

Closing a struct is equivalent to adding ..._|_ to it.

but it's not clear what {..., ... _|_} should mean, which is what that sentence implies
would happen when there's an ellipsis already present.