Dirkjan Ochtman

Yeah, I decided to take this direction because I wanted to avoid implementing a parser for all of Rust's pattern matching, but maybe that wasn't such a great decision after...

I'm not sure what you tried but I'm pretty sure there are ways to access the data in the tuple form, too.

Yes, that's exactly right. The closure is also just a function handler, just using a more compact syntax.

Seems like that this should be pretty clear to most more experienced Rust users, but if someone submits a PR I'd be happy to review and merge it.

It might make sense to have `abs` also take a reference, maybe I just missed that in review?

Maybe we can come up with a local trait `MaybeDeref` with blanket impls for `T: Copy`, `&T where T: Copy`, `&&T: Copy`, etc?

How many levels deep does your tree go? Currently I think you can go up to about 64 levels before you run into overflow. You can try with this PR:...

Ah, I think that makes sense. For now you can use this workaround: https://github.com/djc/askama/issues/105#issuecomment-483937352.

I unpinned both of these issues again. In my opinion, matching Jinja feature-for-feature is a non-goal. I'd prefer to build something smaller and only add features if there are requests...

My issue with pinning these is that it could convey a signal to others browsing the issues that matching Jinja feature for feature is a goal, which I'd prefer to...