Explore CUE postfix aliases experiment for generated code

[myitcv]

Is your feature request related to a problem? Please describe.

helm2cue generates CUE that sometimes needs to refer to the current scope or bind names during traversal. For example, range comprehensions produce for k, v in #values.x { ... } patterns, and helper call sites use struct unification (_helper & {#arg: expr}).out to pass context. The current generated code is functional but can be verbose, especially in nested traversals.

Describe the solution you'd like

CUE's proposed postfix aliases experiment (cue-lang/cue#4014) introduces a unified ~ syntax for aliases, a self keyword for referring to the current scope, and keyOf/refOf/valueOf builtins. This could improve the generated CUE in several ways:

• The self keyword could simplify patterns where the generated code needs to reference the enclosing struct value.
• Postfix aliases in comprehensions (members.*~M.children.*~C) could make nested range patterns more readable.
• keyOf/refOf/valueOf could simplify dynamic key patterns that currently use string interpolation or index expressions.

Explore this experiment to:

1. Identify specific patterns in the generated CUE that would benefit.
2. Evaluate readability improvements for real chart output.
3. Provide feedback on the proposal from a code generator's perspective.

Additional context

Upstream discussion: cue-lang/cue#4014

[myitcv]

Analysis: Postfix Aliases Experiment Impact on helm2cue

This analysis is based on the postfix aliases proposal (discussion #4014) and a review of all generated CUE patterns in helm2cue.

Background

The postfix aliases experiment proposes a ~ (tilde) postfix operator that creates a reference alias for the current node, and a self keyword that refers to the current composite. The key new syntax:

• field: expr ~ name — binds name to the value of field
• self — refers to the enclosing composite (struct or list)

Pattern 1: Helper struct invocation — (_helper & {#arg: expr}).out

This is the most pervasive pattern in helm2cue output. Every parameterised helper is called by unifying with an argument struct and extracting .out:

replicas: [if (_nonzero & {
    #arg: #values.replicaCount
}).out {
    #values.replicaCount
}, 1][0]

_simple_app_chart: strings.TrimSuffix((_trunc & {
    #in: strings.Replace("\(#chart.Name)-\(#chart.Version)", "+", "_", -1)
    #n:  63
}).out, "-")

Impact of self: The proposal's self keyword does not directly simplify this pattern. The verbosity comes from the unification-then-extract idiom ((X & {args}).out), not from self-reference. The helper must receive arguments somehow, and self addresses a different problem (referencing the enclosing struct from within it).

Potential with ~ aliases: If ~ could name the result of a complex expression inline, it might help in some cases, but the current usage already names the helper via a hidden field (_nonzero, _trunc), so there's no naming gap.

Verdict: Minimal impact. The helper invocation pattern is driven by the need for parameterisation, which neither self nor ~ directly addresses. A more impactful language change would be first-class parameterised definitions (functions), which is a separate discussion.

Pattern 2: Helper struct definitions with #arg

Helper structs use #arg as the input parameter:

_nonzero: {
    #arg?: _
    out: [if #arg != _|_ { ... }, false][0]
}

_simple_app_serviceAccountName: {
    #arg: {
        name!: bool | number | string | null
        ...
    }
    #arg.name
}

Impact of self: Inside _nonzero, the helper already has access to #arg as a field — there's no need for self to reference the enclosing struct. The pattern doesn't suffer from the inability to reference the current node.

Verdict: No impact.

Pattern 3: Conditional default values (the [if cond {val}, default][0] idiom)

helm2cue generates this pattern extensively for {{ if }}...{{ else }}...{{ end }} and {{ default }}:

imagePullPolicy: [if (_nonzero & {
    #arg: #values.image.pullPolicy
}).out {
    #values.image.pullPolicy
}, "IfNotPresent"][0]

Impact: The try experiment (issue #110) is more relevant here. Neither self nor ~ simplifies the conditional-default pattern.

Verdict: No impact.

Pattern 4: for comprehensions with range variables

Range loops use for _, _range0 in bindings:

ports: [if (_nonzero & {
    #arg: #values.ports
}).out for _, _range0 in #values.ports {
    name:          _range0.name
    containerPort: _range0.containerPort
},
]

Impact of ~ in comprehensions: The proposal mentions postfix aliases could work in comprehension contexts. However, the current for _, _range0 in #values.ports pattern is already clear — the binding _range0 serves as the iteration variable. A ~ alias wouldn't reduce this.

Verdict: No impact.

Pattern 5: Struct helper embedding at call sites

Struct helpers are embedded at their call sites:

metadata: {
    name:   _simple_app_fullname
    labels: _simple_app_labels
}

serviceAccountName: _simple_app_serviceAccountName & {
    #arg: #values.serviceAccount
    _
}

Impact of self: In the serviceAccountName case, the embedding uses _ to open up the result. self could theoretically be useful if we needed to reference other fields in the same struct, but that's not the pattern here.

Verdict: No impact.

Pattern 6: _nonzero type testing with _|_ checks

The _nonzero helper uses a cascade of type tests:

[
    if (#arg & int) != _|_ {#arg != 0},
    if (#arg & string) != _|_ {#arg != ""},
    if (#arg & float) != _|_ {#arg != 0.0},
    if (#arg & bool) != _|_ {#arg},
    ...
    false,
][0]

Impact of ~: If ~ could alias intermediate results (e.g., (#arg & int) ~ intArg), it might slightly improve readability, but these expressions are short enough that aliasing wouldn't help much.

Verdict: Negligible impact.

Summary

Pattern	Frequency	self impact	~ alias impact
Helper invocation (X & {args}).out	Very high	None	None
Helper definition with #arg	High	None	None
Conditional default [if...][0]	High	None	None
for comprehensions	Medium	None	None
Struct embedding	Medium	None	None
Type testing cascade	Low (1 def)	None	Negligible

Conclusion

The postfix aliases experiment has minimal to no impact on helm2cue's generated CUE patterns. The core verbosity in generated code comes from:

1. The unification-based parameterisation idiom ((_helper & {#arg: expr}).out) — this is a limitation of CUE not having first-class functions/parameterised definitions, which is orthogonal to aliasing.
2. The conditional-default idiom ([if cond {val}, default][0]) — better addressed by try (issue Explore CUE "try" experiment for optional field handling #110).
3. The _nonzero truthiness helper — better addressed by a standard library builtin.

Neither self nor ~ provides a simplification path for any of these patterns. The experiment is valuable for other CUE use cases (schema composition, self-referential constraints), but the patterns generated by helm2cue don't exercise the problems that postfix aliases solve.

No code changes to the converter are anticipated regardless of the experiment's outcome.