Proposal: User-Provided Functions and Validators

[rogpeppe]

📋 Proposal Details:

• File: designs/4293-user-functions-and-validators.md
• Status: Draft

---

This proposal introduces a Go API for wrapping ordinary Go functions as CUE-callable functions and validators. It provides a simple, type-safe mechanism for extending CUE's evaluation with custom logic, establishing two distinct concepts: functions (which compute new values from arguments) and validators (which constrain existing values through unification).

See the design document for full details.

This proposal is closely related to #4294 (CUE Value Injection) and #4295 (Tagged String Literals).

[mxey]

This separation does not reduce generality. A function can return a validator value, allowing patterns like #minLen(3) & "hello" where #minLen is a function that returns a validator. This composes naturally with CUE's existing constraint model.

Very neat.

I assume using a validator in an if condition would work with the unifying operator, so generality works in the other direction.

Both NewPureFuncN and ValidatorFunc accept optional FuncOption values.

I am personally not a fan of functional options and would prefer an options struct. They are easier to overview at the call site and don’t pollute the API docs. It might also play better with an RPC extension, since structs can more easily be transported.

Non-concrete arguments. All arguments must be fully resolved CUE values. Non-concrete argument values are not currently supported, although they could be.

Obviously this should eventually be supported. Would that work transparently by the registered Go function taking a cue.Value, or would that require a new registration function? If it’s the latter, I would suggest putting “Concrete” in the proposed function names.