Exposing Default CEL checker.CostEstimator and interpreter.ActualCostEstimator

[jon-whit]

Is there a specific reason not to expose the default implementation of the checker.CostEstimator and interpreter.ActualCostEstimator? I'm looking at adding cost estimation to a base CEL environment and if the estimate exceeds a max cost estimate then I would reject the expression prior to accepting it. What would be the best way to make use of the standard CEL library to achieve this given this functionality is not exposed as public signatures yet?

[jon-whit]

cc'ing @TristonianJones - I've seen you helping various people in the community with CEL cost stuff. Seems you may be the best point of contact for this 🤷 ?

[TristonianJones]

@jon-whit The main reason for the lack of a default estimator is that complex types in CEL don't have a built-in notion of size, so the default implementations for the type-check and interpreter would basically always return nil to indicate there's no estimate. It can be done, but I hadn't gone so far as to do this since it seemed like this should indicate that more work needs to be done by the caller to provide actionable estimates. Providing an implementation that returns nil for each method is the equivalent to the default implementation.

Also, I exposed custom cost overrides as something that could be configured on a per-method/overload basis if you're looking to package your functionality up as a library: https://github.com/google/cel-go/pull/850/files

Let me know if this is what you're looking for.

Cheers,

-Tristan