Add new reject filter#430
Conversation
|
Should we (try to) implement closures like |
| For more control over the filtering, you can use a callback instead. Declare a function: | ||
|
|
||
| ```jinja | ||
| fn is_odd(value: &&u32) -> bool { |
There was a problem hiding this comment.
Were does the second reference come from?
There was a problem hiding this comment.
The filter method. Made me sad too.
| /// ``` | ||
| pub fn reject_with<T: PartialEq, F: Fn(&T) -> bool>( | ||
| it: impl IntoIterator<Item = T>, | ||
| callback: F, |
There was a problem hiding this comment.
Can you please make this F: FnMut…, mut callback: F?
| /// ``` | ||
| pub fn reject<T: PartialEq>( | ||
| it: impl IntoIterator<Item = T>, | ||
| filter: T, |
There was a problem hiding this comment.
Maybe better filter: &T, with an additional &(…) in the generated code. This way (I think) the type-coercion might work better if the input is already an &T.
There was a problem hiding this comment.
So you mean two &&? There is one already.
There was a problem hiding this comment.
Anyway, added a second one.
There was a problem hiding this comment.
No, that's not what I meant, but I confused myself with my comment. Let me think for a second or 86400. :)
I thought about it and concluded that we definitely didn't want to implement closures in our parser. |
899ec9a to
6530cea
Compare
* Re-use iterator getting from `{% for %}`'s implementation
* Don't use edition 2024 features
|
I tried to get rid of the second reference, but I failed. :( Still, I think that the changes I came up with during my tests could be useful. Please have a look. |
|
Looks good to me (can't approve if it's on my PR 😞). |
|
Show off. 😛 |
|
Oops, the filter is not display wrapped. I don't think it would be matter, actually, because |
This one is interesting because whether you give it a path or a value, it will not call the same rust function. Found it interesting so implemented it.