Replies: 3 comments 7 replies
-
|
Adding notes here from a thought offline, so that I can record the thought... and the answer! I’m trying to sanity-check how In CUE terms this breaks down as:
Taking a GitHub Actions flavoured example: What I want is essentially the implication: i.e. if My understanding of the That leads to two questions:
For the avoidance of doubt: I’m not arguing |
Beta Was this translation helpful? Give feedback.
-
|
Per our conversation earlier @mpvl, just dropping in some notes here. No action required, just capturing so that I don't lose them. Somewhat inspired by this example from the proposal: I wondered out loud whether we even "need" Given the above, it would be a "hard" error in case Granted this is all rather hand wavey, but that intuition is all my brain can handle! You kindly pointed out some problems with this approach, specifically the case that the nested We discussed the fact that this could equivalently be rewritten in "my" approach as: Perhaps lots of my "concern" here is whether You also shared some of the challenges in finalising the design of And finally as a rather "out there" suggestion, I mentioned the potential overlap with an idea we both separately had regarding #1325. Specifically, that in the case of current That is to say that declarations (by which I mean the entire line above, the path and the value - apologies if this is not the correct term) are not "ready" in the case that |
Beta Was this translation helpful? Give feedback.
-
|
Is |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
📋 Proposal Details:
Proposal: add a
tryconstruct to handle optional fieldsSummary
This proposal introduces a
tryconstruct to elegantly handle optional fields in CUE configurations, addressing a long-standing source of verbosity and error-prone patterns in the language. Currently, working with optional fields requires explicit existence checks using verboseif exists()statements, and common workarounds using disjunctions (like*foo[a.b] | "fallback") can silently swallow errors when fields are unexpectedly missing—a major source of bugs in CUE configurations.The proposal introduces two complementary features: the
?notation for field references (e.g.,a?,user?.name?) to mark that a field may not exist, and thetrycomprehension clause that evaluates expressions containing these optional references without producing errors when they're undefined. Together, these features enable concise expressions likex: try { foo?[a?.b]? } else { "fallback" }to replace complex nested conditionals. Thetryblock will simply be discarded if any?-marked field is undefined, with an optionalelseclause providing fallback values.Beyond reducing verbosity, this design creates a symmetry between optional field declarations (
field?: type) and their references (field?), enabling better tooling support for detecting potentially brittle code. The explicit marking of optional references makes configuration intent clearer and helps prevent accidentally suppressing errors. The proposal also ensures CUE queries maintain the same semantics as regular field references, leading to more robust and predictable behavior compared to other query languages.The design carefully scopes the feature to handle only field existence checks, not general conditional logic based on concrete values. Future extensions could include automated detection of error-prone references and conditional field definitions, further improving CUE's reliability and developer experience.
[Summary generated by Claude AI]
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:
Last updated: 2025-08-05 18:48:59 UTC
Beta Was this translation helpful? Give feedback.
All reactions