Confusion about optional value in evaluating

[chivalryq]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Here is an simple example

parameter: {
	a?: int
}
output: {
	output_a?: parameter.a
	y:  1
}

parameter: {
	a: 1
}
// export result
//{
//    "parameter": {
//        "a": 1
//    },
//    "output": {
//        "y": 1
//    }
//}

IMO output_a should be 1. I'm new to cuelang and did I miss something? Is this a feature or bug?

thx for your explanation!

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[seh]

I understand the desire. At present, at least, CUE doesn't work like that. Instead, you need to write the following:

parameter: {
	a?: int
}
output: {
	if parameter.a != _|_ {
		output_a: parameter.a
	}
	y:  1
}

Note that the comparison against bottom (_|_) is imprecise. See #822 for the proposed numexists and numconcrete builtin functions that would be more precise alternatives.

[verdverm]

Given:

p: a: 1
o: a?: p.a

I would expect o: a: 1 in the result, however it is o: {} which is definitely counter intuitive or a bug.

This could be simplified to

p: 1
o: a?: p

which results in o: {}

This seems more so like a bug or very counterintuitive

[myitcv]

@chivalryq - @seh is right to point you towards #822, in particular the section regarding printing modes. Because under that proposal, the need for ? largely disappears, and instead manifestation of values becomes a function of concreteness.

@verdverm this is behaving as expected for optional fields.

I'm going to close this as working as intended, because the issues raised here are covered by #822.