Consider supporting Expression Statements

[joshuataylor]

In Jinja, there is an extension called "expression statements":

https://jinja.palletsprojects.com/en/3.1.x/extensions/#expression-statement

The “do” aka expression-statement extension adds a simple do tag to the template engine that works like a variable expression but ignores the return value.

These are super handy, you can do things like this:

https://jinja.palletsprojects.com/en/3.1.x/templates/#expression-statement

Thoughts? (Happy to submit this)

[mitsuhiko]

Since MiniJinja has no real mutables, I'm not sure if this is super useful. Do you have an actual example in mind in MiniJinja?

[joshuataylor]

Sure, so my usecase is that dbt-utils (a helper library for dbt, I'm going to be talking about this a bit, sorry 🥲) uses this for when a function/macro returns something that we want to ignore.

All I think it really does is consume the output of the macro/functions calls? So in the parser we would add a "Do" block with a parse_expr_noif, in the compiler actually execute it but don't show the output?

I'd be happy to contribute this feature.

[mitsuhiko]

I'm not opposed but I'm curious how these macros or functions have side effects. I assume this would always have to go through some dynamic object exposed to the template?

[joshuataylor]

Yep, so for example run_query would execute and return results, so it's dynamic.

[mitsuhiko]

Right. But in that case if you don't use the return value why fire the query? The utility of {% do %} in Jinja2 is for instance that you can append to a list. That's an operation that is not supported in MiniJinja because values (other than dynamic objects) are immutable, so I'm trying to understand what the practical use case for this is.

[mitsuhiko]

@joshuataylor is this issue still relevant?

[joshuataylor]

It was mostly for BC to support existing code, but decided to just not support it :).

So happy for this to be closed.