Jan Procházka

I think I'm generally against adding container-level validation if the use-cases can be served by more specific rules. The case of "I want custom validation on the container" should only...

> you cannot derive it anymore The fact that you can't derive parts of that `Validate` impl seems reasonable to me. Everything in this library is built with extensibility in...

It's not pretty, but you can work around the lack of struct-level validation using a newtype and a custom rule on the inner type: ```rust #[derive(garde::Validate)] #[garde(transparent)] struct X(#[garde(custom(at_least_1))] Inner);...

I'm not sure if that would do what you want, the resulting error's path will contain the `a` field, `value.a: at least one element must be present` ```rust #[derive(garde::Validate)] struct...

I was very confused by this behavior when investigating it, because `anywidget` doesn't actually do anything that would result in a memory leak. It turns out that this is a...

> For URLs created using URL.createObjectURL which are subsequently revoked, the cache could evict the module, because it isn't possible for it to be re-imported anymore. No browser does that,...

I believe this issue would be a prerequisite to using `ehttp` in this crate: - https://github.com/emilk/ehttp/issues/64

Hey, I'm currently working on this. The plan is to completely replace `reqwest` with `ehttp`, meaning without retaining support for `reqwest`, `tokio`, etc., and replacing all `async` code with equivalent...

Note: This is a tracking issue for setting the limits _globally_, not configuring them manually in each place. The latter is only a bandaid fix.

I don't know either, given that it requires more research I'd consider this hard/high-risk rather than easy. I'd rather remove it from the milestone