Feature Request: Idiomatic way to mimic Option::map

[msrd0]

This is very straight-forward in rust code, where we can simply write

// ver is of type Option<&str>
let suffix = ver.map(|ver| format!("-{}", var)).unwrap_or_default();

In askama, however, this code is much longer and less readable:

{% let suffix -%}
{% match ver -%}
  {% when Some with (ver) -%}
    {% let suffix = format!("-{}", ver) -%}
  {% when None -%}
    {% let suffix = String::new() -%}
{% endmatch -%}

It would be nice if askama had a better way to mimic Option::map, either supporting rust closures, or introducing a custom syntax for this.

[vallentin]

If the feature request is only about closures, then this is a duplicate of #284. As djc already mentioned in that issue, the problem is that adding closure support essentially requires adding support for all valid Rust syntax.

If it's a reusability problem, then you could create a macro or implement it as a function in Rust.

fn suffix(ver: &str) -> String {
    format!("-{}", ver)
}

Then within your template you can do close to what you wanted originally.

{% let suffix = ver.map(self::suffix).unwrap_or_default() %}
{{ suffix }}

{# or just #}

{{ ver.map(self::suffix).unwrap_or_default() }}

[msrd0]

I think this is neither - I don't want above code anywhere in my template because my first impression would be what is this? and then, after understanding the code, why is that written so complicated?. Neither am I asking askama to support closures. I just want some syntax that makes it easier to deal with Options, without specifying how that's exactly going to look - personally, I'm a fan of the Kotlin-esque ver?.let { "-$it" } ?: "" syntax, but that probably looks alien to people that are just used to Rust syntax.

What you suggested seems to me more like a workaround than a fix.

[djc]

So far I've tried to avoid inventing too much syntax that isn't either (a) already in Rust or (b) already in Jinja et al and maps naturally to Rust code. If we invent syntax here, that becomes something that every user of Askama potentially has to learn, so I feel that the onus is on me to be careful about inventing things that fit in well with the rest of the design.

Another option here that hasn't been mentioned is a custom filter.

[vallentin]

Of course, that's why I said if it was only about closures. I was just trying to shine some light on alternatives, in case you didn't know.

All new ideas for dealing with Options/Results are welcome. I think I understand the example you're giving. So if all variables are non-null then it results in the formatted string otherwise empty string? The immediate issue is that unless all variables in the format string are Options, then it might become an issue, as the generator cannot infer the types of variables.