Functions with vars in their ref aren't disallowed at parse-/compile-time

[johanfylling]

The following module compiles without issue:

package test

p := a.b.c(2)

a.b[c](x) := x {c = "c"}

a.b[c](x) is however an "unreachable" function, as the var c is defined by calling and evaluating the function. Executing the policy will generate the error: policy.rego:3: rego_type_error: undefined function data.test.a.b.c

Even if we modify the module, adding a constant c that is know ahead of evaluation, evaluation will generate the same rego_type_error:

p := a.b.c(2)

a.b[c](x) := x 

c := "c"

Expected behavior

Functions with vars defined in their ref should be disallowed at parse- or compile-time.

[ashutosh-narkar]

Just to understand this, OPA does generate the error at eval time and you're suggesting this should happen sooner? Are there cases where the policy needs to evaluated first to report such errors?

[johanfylling]

Correct. I have a hard time dreaming up a scenario where it would be beneficial to even have dynamic components in a function ref. Unless there's an argument not to, I think a simple rule to enforce at parse-time would be to require all function refs to be ground; i.e. no var components.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.

[anderseknert]

I have a hard time dreaming up a scenario where it would be beneficial to even have dynamic components in a function ref

Dynamic policy composition, but with the inputs provided via args rather than via with and the caveats that comes with that. If this worked, it would be possible to have a main policy query any matching function dynamically, allowing functions to define dynamic requirements that could be added or removed by teams depending on their use case. More on that in this issue. Obviously, compile time checks of args and return values can't work for anything resolved at eval time, but I can think of some cases where that would be acceptable.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.