Use experiments in `--expression` flags.

[tvandinther]

Is your feature request related to a problem? Please describe.
I'd like to be able to try experiments fully which includes using them in flags which accept CUE expressions.

Describe the solution you'd like
For example, with the aliasv2 experiment I'd like to be able to run the following command:

$ cue eval test.cue -e 'self & {y: 2}'
predeclared identifier "self" requires @experiment(aliasv2):
    --expression:1:1

Describe alternatives you've considered
None identified.

Additional context
https://cuelang.slack.com/archives/C012UU8B72M/p1772789199811189

[mvdan]

For self this is not a hard problem, given that it's a new predeclared identifier that's largely backwards compatible. For other language experiments this is much trickier, e.g. explicitopen changes the closedness semantics, and aliasv2 swaps one syntax for another. In practice we could make educated guesses or use fallbacks in most cases, but I worry that such logic would be rather complicated to document and understand.

Needing to enable an experiment as part of an expression string also feels too clunky, e.g. cue export -e '@experiment(aliasv2), self & {y: 2}'.

I think a reasonable answer could be to support module-wide experiment directives, as I suggested in #4154 (comment), and having those apply to CLI expressions when using the CLI inside that module as well. Technically, a CLI expression is not within a module, but if it's being used in the context of a module, I think it's reasonable to treat it that way.

[tvandinther]

When it came to the evalv3 experiment we could use an environment variable and in the Go API I also noticed that this was an option when creating a CUE context. Is this mechanism viable for all experiments? Or do language experiments really require being flagged on a per file (or per module as proposed) basis?

[mvdan]

evalv3 was different because it was a global experiment, whereas language experiments can be applied on a per-file basis without being applied globally. A global experiment like evalv3 could not be applied on a single file or module, because it's impossible to mix two evaluator versions in one invocation.

That said, there's no reason that we couldn't offer a global route to flip a per-file experiment. My intuition is that it may add complexity or confusion, e.g. if a global flag attempts to disable an experiment that is enabled by language.version in cue.mod/module.cue or vice versa. That said, Go's GODEBUG flags can be set both via an env var and via go.mod directives, so I guess people don't find that too confusing.

I still think it probably makes sense to add support for experiment knobs in cue.mod/module.cue, because that is useful in itself, and see how far that gets us in terms of CLI support. We can then think about other routes like an env var or more CLI flags as an additional step.