Skip to content

ast: Allow empty rule bodies - #8870

Draft
anderseknert wants to merge 1 commit into
open-policy-agent:mainfrom
anderseknert:normalize-not-having-a-body
Draft

ast: Allow empty rule bodies#8870
anderseknert wants to merge 1 commit into
open-policy-agent:mainfrom
anderseknert:normalize-not-having-a-body

Conversation

@anderseknert

@anderseknert anderseknert commented Jul 8, 2026

Copy link
Copy Markdown
Member

Since the dawn of time, unconditional rules have been represented internally like this:

head := value if {
    true
}

head contains value if {
    true
}

For about as long, the lone "true-expression" has been a bit of an eye sore. A few nights ago, I set out to see how much of OPA would break if we tried to get rid of this, and allow this type of rule to be represented internally just like how it's written:

head := value

# or..

head contains value

# .. or .. 

Turns out, not a whole lot at all broke, and this is currently in a state where all tests but ONE (TestConcurrencyCompile) passes on my own machine. I don't fully understand why, so I'd appreciate some help with that!

But more than anything, this is a request for feedback. Is this a bad/good idea? Would we break anything somewhere? The lone true expression feels like more of an implementation detail to me, but considring how long it's been around, who knows if someone has come to rely on that somehow..

Since the dawn of time, unconditional rules have been represented
internally like this:

```rego
head := value if {
    true
}
```

For about as long, the lone "true-expression" has been a bit of
an eye sore. A few nights ago, I set out to see how much of OPA
would break if we tried to get rid of this, and allow this type
of rule to be represented internally just like how it's written:

```rego
head := value

head contains value

```

Turns out, not a whole lot at all broke, and this is currently in
a state where all tests but ONE (`TestConcurrencyCompile`) passes
on my own machine. I don't fully understand why, so I'd appreciate
some help with that!

But more than anything, this is a request for feedback. Is this a
bad/good idea? Would we break anything somewhere? The lone true
expression feels like more of an implementation detail to me, but
considring how long it's been around, who knows if someone has
come to rely on that somehow..

Signed-off-by: Anders Eknert <anders.eknert@apple.com>
@anderseknert

Copy link
Copy Markdown
Member Author

I'd love to see some benchmark metrics on this later! Regal shows little impact in terms of allocations, but seems consistently 4-5% faster on linting itself.. which is not little!

@stale

stale Bot commented Aug 8, 2026

Copy link
Copy Markdown

This pull request has been automatically marked as stale because it has not had any activity in the last 30 days.

@stale stale Bot added the inactive label Aug 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant