Field optionality is stripped when field name contains a reference

[ghdkjs-cue-works-jonathan-matthews]

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

Tested on both 0.4.3 and 0.5.0 beta 2.

Does this issue reproduce with the latest release?

Identical (testscript) behaviour on both 0.4.3 and 0.5.0 beta 2.

What did you do?

I'm trying to emit some CUE that contains an optional field named via a reference.

What did you expect to see?

Here's a testscript:

exec cue eval foo.cue -e test
cmp stdout expected
-- expected --
foo?: number
-- foo.cue --
package p

y: "foo"
test: {
	(y)?:    string
	"\(y)"?: string
}

What did you see instead?

cue eval showed me foo: number instead of foo?: number.

Knowing that cue eval is perhaps seen as being secondary to cue def, I believe the following is also notable.

I'm not sure how to encode this in a testscript reproducer, but running cue def on the input file provided shows that the optionality appears to have been stripped even at this stage of evaluation/parsing:

cue-0.4.3 def foo.cue | cat -n 
     1  package p
     2
     3  y: "foo"
     4  out: {
     5          (y):    string
     6          "\(y)": string
     7  }
$ cue-0.5.0-beta.2 def foo.cue | cat -n 
     1  package p
     2
     3  y: "foo"
     4  out: {
     5          (y): string
     6          foo: string
     7  }

Note that lines 5&6 (repeated as different forms just in case the optional syntax interacted differently with string-interpolated names) /already/ have their optionality removed, across both 0.4.3 and 0.5.0-beta.2.

This minimal reproducer is part of some work I'm doing around parsing a vendor-provided, custom schema, and emitting it in CUE for others to consume. I mention this because I know that, on its face, this Issue may not appear particularly important, but I believe it'll be a subtle but significant blocker for folks trying to help increase CUE's ecosystem interoperability. IMHO this is important so as not to block "how can we empower/enable others to work on json/yml format X at scale?" questions on "the schema format needs to be implemented inside the core CUE project, so it can be cue import'ed". Optional fields in schemas, where the CUE that transforms the schema into human-readable but CUE-enforceable files has to emit fields with names that are derived from other fields are, IMHO, unavoidable!

[jpluscplusm]

Whoops! I wasn't signed in with my @jpluscplusm account when raising this Issue 🙄 I'm fine with any admin wanting to delete this, and I'll re-raise it under the appropriate user :-) Or not - I'm happy either way ...

[jpluscplusm]

Here's a testscript showing there's an output difference between optional fields with fixed names and dynamic names, even when the dynamic name is made concrete:

exec cue eval .:p --show-optional
cmp stdout expected
-- foo.cue --
package p

y: "foo"
out: {
	bar?: string
	(y)?: string
}
-- expected --
y: "foo"
out: {
    bar?: string
    foo?:  string
}

[rogpeppe]

Duplicate of #2107.