Implement getField CEL function

[ghost]

I think it has to be a global overload, a member overload would require a generic on the receiver which doesn't seem possible.

I'm proposing this as an eventual replacement (before 1.0) of our hack around the fact that the in identifier is reserved in CEL. This is especially urgent for protovalidate-cc which is currently carrying patches to the CEL implementation in order to enable it, since cel-cpp doesn't allow this sort of functionality to be added in at runtime.

Protovalidate PR: bufbuild/protovalidate#352

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / validate-protos (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Apr 22, 2025, 11:52 PM

[rodaine]

Could use traits.Indexer?

[ghost]

lol, yeah. Fixed

[rodaine]

Also, re:

a member overload would require a generic on the receiver which doesn't seem possible.

If you make the receiver type dyn, I think it would work?

[ghost]

Oops, I saw this after me and Nick moved to merge the protovalidate PR. I've been pondering but I think it's not worth losing too much sleep over; we're still pre-1.0 so we can always try to make this prettier later, especially since the protovalidate protobuf descriptors used for standard constraints are always strongly tied to the implementation version.

(I think if we try to do that, most likely we'd run into problems with at least some of the CEL runtimes, whereas this approach works on all five. That said, we can workshop it. If we really hate free functions we could always do something evil like "field".indexInto(message).)