Anders Eknert

Hmm, assuming the or is in the rule body, that’d still give you undefined on missing phone number, would it not?

Lol, sure, but that'd equivalent to: ```rego has_phone_number if input.phone_numbers.work ``` and the `||` makes no difference in that case, is all I'm saying :) Regal rule coming in 3......

Great points, Stephan. I guess we can't change how `not` works in existing policies but `import future.keywords.not` (or `import rego.v2` or whatever) for how we'd want `not` to work could...

> My concern is user expectations, and that maybe using the || infix for something that's in all other ways actually an alternative op Isn’t that how **or** works in...

I too would prefer that we called it `or`. It's the most readable option, stylistically "matches" `not`, and while expectations may vary to some degree, its behavior would likely be...

Possible duplicate of https://github.com/open-policy-agent/opa/issues/3167 Which is fine of course :) We might want to close one of them though.

Just saw a different error message about this, which was... interesting :) and perhaps a case to remember when this is fixed one day: ```rego package p for.foo.f(_) := 1...

Thinking about it more, I guess we could even provide a way for the `aggregate_report` rules to be provided the data in the same format as they're currently served. This...

> If any of the policies have rules defined with the same name (yet still different package namespace), eval will fail with the "multiple default rules found" error. That shouldn't...

Feel free to create a feature request for that too! The topic of multiple/nested configurations have been discussed before, and while there are some advantages to that, there might also...