This sort of parameter without a name makes it difficult to understand a template worth reading the template docs. I'd been inclined to either:

1. Replace a naked bool parameter with an enum that self documents (that may look verbose here), or
2. Replace a bool with a second named method. E.g. default_if_undefined might be a good name for the false branch. Alternatively default_if_none / err

I added a line that {{ variable_or_expression | default(default_value, boolean = true) }} works, too.

I'd still prefer explicit over implicit a bit. This is based on an assumption that the direction of askama is a jinja-like template library with natural rust idioms rather than a jinja compatible template library that adds rust conveniences. I'm not sure whether that assumption is correct however (intuitively I'd lean towards the former as being more useful)

As a single data point. Having not seen the jinja syntax for the default filter prior, even with the parameter named boolean in the CoPilot suggestion rather than the bare true, I still had no idea from reading it what that parameter meant or controlled seeing it for the first time. This suggests to me that it is poorly named in jinja, and something that we could make better pretty easily with good naming here.

Does this break semver (in a way that matters) for any consumers?
If so, would be worth keeping as Pluralize rather than version bumping the lib?

Well, version bumping will be needed since we plan to extend {% call %} blocks. So it's fine.

The type was unreachable before, so its name did not matter.

This isn't a syntax I've seen before, what's the rationale behind it?

To prevent impacting the upper scope.

In here I mostly use it like a #region. Every DefaultFilterable is in this scope and one click hides everything.

Got it. I know that often there's a tendency for larger module sizes in some Rust projects. This seems to be a symptom of that. I tend to address the same core problem (strongly related code that isn't in the outer scope) by using smaller narrower module (files) and liberal re-exports instead. This keeps the unit tests fairly close to the code it's testing, makes it easy to navigate and find code, etc. Obv. this is subjective, but maybe something to think about in future.

So a soft suggestion to extract this to filters/default.rs or something.

I'd still prefer explicit over implicit a bit. This is based on an assumption that the direction of askama is a jinja-like template library with natural rust idioms rather than a jinja compatible template library that adds rust conveniences. I'm not sure whether that assumption is correct however (intuitively I'd lean towards the former as being more useful)

As a single data point. Having not seen the jinja syntax for the default filter prior, even with the parameter named boolean in the CoPilot suggestion rather than the bare true, I still had no idea from reading it what that parameter meant or controlled seeing it for the first time. This suggests to me that it is poorly named in jinja, and something that we could make better pretty easily with good naming here.

Got it. I know that often there's a tendency for larger module sizes in some Rust projects. This seems to be a symptom of that. I tend to address the same core problem (strongly related code that isn't in the outer scope) by using smaller narrower module (files) and liberal re-exports instead. This keeps the unit tests fairly close to the code it's testing, makes it easy to navigate and find code, etc. Obv. this is subjective, but maybe something to think about in future.

So a soft suggestion to extract this to filters/default.rs or something.

It could be worth adding a unit tests for the various implementations of this that captures each implementation. E.g.:

assert_eq!(0_u8.as_filtered(), Ok(None));
assert_eq!(1_u8.as_filtered(), Ok(Some(1));

should be

duplicate line - needs to be fixed or state what's going on here.

This should maybe describe how this works without having to link to the jinja / the other filters.

This actually suggests a bit of a jinja / rust impedance mismatch here. In Rust, we have a few different operations like map_or_default and unwrap_or_default. Intuitively, var | default when the type of var implements the Default trait seems like it would be obvious that it should return default. I know that a user could call .unwrap_or_default() or whatever there, but I'm curious whether it might be worth extending this to allow the obvious intuitive thing there. (I'm not fully certain of this, either way, WDYT?)

The default filter is not a great fit for rust, but sadly, I'm not sure if we can go around this issue in an elegant way without making it harder for both jinja and rust users to be confused. At least with this, jinja templates work with askama...

Comments explaining what the test checks is very appreciated, thanks! :)

I didn't know we could do that in rust, it looks super nice! (and will look even better once I add the spans to the generated TokenStream :3)

The feature is already stable for over a year: https://releases.rs/docs/1.78.0/, but I am not sure if I ever saw it in the wild. I found it in the standard library and simply tested if library developers can use it, too. :)

A lot of features are, but if I don't use them, I simply forget about them. ^^'