Eliminate Embedding-Based Struct Opening Semantics

[mpvl]

📋 Proposal Details:

• File: designs/language/4032-ignoreclosed.md
• Status: Draft

---

Eliminate Embedding-Based Struct Opening Semantics

This proposal eliminates the implicit opening of closed structs through
embedding and introduces an explicit postfix ... operator for
recursively opening composite structs.
This change simplifies CUE's semantics, reduces user confusion, and enables
clearer expression of type extensibility patterns.

---

Full Proposal

The complete proposal with all technical details, examples, and implementation notes can be found in the proposal document.

How to Comment

Please provide feedback on this proposal:

• For general discussion: Comment in this GitHub discussion
• For detailed code review: Comment on the Gerrit CL (link will be added when available)

Last updated: 2025-08-19 11:42:24 UTC

[mvdan]

I completely failed to find this issue via search, as it doesn't mention the explicitopen experiment which is now active. Adding the comment here to add the mention :)

[myitcv]

Linking here to #3772 which discussed whether imported package values should be non-recursively closed or not. It's interesting to consider that if we did that, then package values themselves could be trivially used as closed schemas:

package p

import "example.com/q"

// Case 1: explicitopen accepted, and package values closed on import
q

// Case 2: explicitopen accepted, but package values left open per today
close(q)

Noting thought that with case 2 it's not exactly terrible to have to close the value imported; more a question of how often that needs to be done by the importer.

[infogulch]

Could authors define a package that is always closed with the self feature? If yes, maybe leave it up to package authors to decide if their package should be closed when imported.

[mpvl]

In light of Issue #4097, I propose a slight change to the "reclosing" rules in the spec:
https://cuelang.org/cl/1221642

In fact, note that the reclosing rules were not defined in the spec at all. Now they are. I propose these reclosing rules make it in for v0.15, as they are kind of fundamental to this feature.

[mxey]

I was skeptical before I read the proposal, but this convinced me:

This change aligns with CUE's principle that a: X should mean the same as a: { X }.

I also like ... as the syntax

[mpvl]

@mxey thanks for the feedback.

Here is an updated spec with an alternative example of using x... for "subclass" types that holds in definitions (even though not entirely the same as before).
The spec should now reflect the current implementation as is.

New spec update: https://review.gerrithub.io/c/cue-lang/cue/+/1221642/21/doc/ref/spec.md

N.B. we are adopting the convention that we have Gerrit CLs with the spec changes on "Hold" as long as an experiment is active. cue help experiments shows all experiments and related links.

[cuematthew]

Ok, I've read issue #4097, I've read the proposal details, I've had a play with the experiment, and I've refreshed my prior thinking on closedness.

There are aspects that I like. For example the fact that x: {a: _, b} is now the same as x: {a: _} & b.

But I am not a fan of how destructive ... is -- it throws away policy, which cannot be recovered.

Closedness can exist on any subtree of a struct. Closedness is policy: it allows you to state the effect of other fields in future unifications. For example:

x: { a: int, b: close({c: 7})}
y: { a: 2, b: { d: _ }}
z: x & y

x.b is explicitly closed. Within x's state, we have specified policy for how subsequent unifications of x.b should handle fields other than c, and sure enough this rears its head when we come to z.

If we wanted to extend x.b, the old semantics gave us a way to do that:

xʹ: {
  x
  b: e: int
}
z_ok: xʹ & {b: e: 12}
z_ko: xʹ & {b: f: 12}

This use case is now not supported. Using x... throws away all closedness policy within x and it is not recoverable. From what I can tell there is now no way to mutate a struct without irrevocably discarding its closedness policies.

@experiment(explicitopen)

x: { a: int, b: close({c: 7})}
xʹ: {
  x...
  b: e: int
}
z_ok: xʹ & {b: e: 12}
z_ko: xʹ & {b: f: 12} // this no longer errors

I'm not arguing in favour of the old syntax or any of the awkward semantics of the status quo. But I think there is a use case that's being dropped here.

[mpvl]

Im my opinion, closedness is much more subtle than that, and it is often only a "soft" constraint. Especially with schema, there is often a duality going on where, on the one hand, you want to allow fields to be added in the future while, on the other hand, you want to error when fields are added now.

A practical example of this is how Protobufs work: if an incoming message has an unrecognized field, it is customary to ignore that field, not error. On the other hand, if you create a Go structure from a Protobuf definition, and you refer to a non-existing field, it errors. The difference is that in the latter case one operates within the scope of a single version (closed), whereas in the latter case one operates in a multi-version world with different rules.

The closedness of CUE definitions is intended to follow this paradigm, where really they can be open and closed at the same time. The ... declaration in structs is overused in my opinion.

So in other words, unless the closing is explicitly done by the user, we should not accept the closedness of a definition as gospel. They are meant to be openable and closable. The postfix ... operator gives the user a lot of control over what the intent is in a specific situation.

BTW, there is an easy way to "reclose" and not throw away "policy". In the above example, it seems that you intend x\`` to be a schema. But if that is the case, you can just declare it as a new definition, in which case the entirety is reclosed and the f` field is enforced as not allowed.

Not reclosing unconditionally on ... also allows for other useful patterns (see the animal example) and, not insignificantly, greatly simplifies the implementation of closedness as it removes some complicated non-local semantics.

One could consider, however, that the ... operator should not apply to explicitly closed structs. We could consider that. It will probably be a semantics that is much harder to transition to, though, and users have been wanting to open up explicitly closed structs.