Ignore incomplete values when exporting to json

[shykes]

I would like to export the concrete parts of a value as Json, without triggering an error on incomplete parts. Any incomplete values in the tree should simply be ignored. Currently cue.Value.MarshalJSON does not seem to support this.

I think I remember that an earlier version of cue export supported this as its default behavior, but that seems to have changed.

Am I missing something obvious?

[mpvl]

As far as I remember, non-concrete values were always forbidden in JSON.

But this does seem reasonable.

In fact, this touches upon a proposal I've been trying to get more feedback on :), one of the few remaining proposals for a backwards-incompatible language change:

Introduce ! as a field marker, and introduce the following rules, w.r.t. exporting:

• field: int: export only if concrete
• field!: int: optional, but needs to be explicitly declared for a complete schema to be valid.
• field?: 1: always optional, don't export, even if concrete.

This addresses several issues:

• It is currently not possible to require a field to be explicitly declared for lists and structs. A user may want to declare that a field is a list of ints (foo: [...]) that the user must specify explicitly. This is currently not possible, as the [...] has the implicit default value of []. For other fields, like foo: int, this is possible, as int still needs to be made concrete (in the current design).

• An extensible API should define most fields as optional. This means in practice that APIs are littered with ?s. Forcing an extra step to make a field optional also makes it easy to make a field required by accident.

With the current proposal, the use of ? would almost vanish, and the use of ! would ostensibly be rare. A ? could still be used to make a concrete value optional (foo?: 1), meaning that a field is optional, but if it is specified, it must be 1.

This would be mostly compatible with the old semantics, but makes export more permissive.
The -c option could be introduced for export to mimic the old behavior. This would also bring it more in line with eval and vet, which would also require that option for non-concrete values to fail.

[seh]

I understand the first two proposed ways of declaring a field, but the third one—?— is confusing. If it's optional, and it's never exported, what is the intended use of the field? Is it like a let expression, intended only for referencing from other fields? Is it intended for transitioning a field that had been required in an earlier version of the schema to now being optional, so that if older conforming values out there still specify the field, we'll check that it remains valid?

[mpvl]

It would be of rare use, but otherwise there is no way to specify an optional field with a concrete value. It will be rarely use, but there are cases where one may want to do this.
Another reason to keep the ? is for backwards compatibility.

[seh]

If I understand you correctly, though, it's backwards compatible in its input syntax only; that it would no longer be exported makes the use of it incompatible.

I'll just say again that I find the purpose and effect to be confusing. If we could just eliminate it, that would save us from having to explain this to CUE users over the next few years.

[cueckoo]

This discussion has been migrated to cue-lang/cue#441.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.