Jan Procházka

I want to avoid adding `params`. Correct me if I'm wrong, but for your use case, wouldn't `code` alone be enough? You should be able to retrieve the internationalized error...

> That's a first step, the problem is if the i18n message associated to the code is something like: "The value must not exceed {max}" > > The params are...

Serializing error reports was implemented in https://github.com/jprochazk/garde/commit/a989bcbfd28a4d7aa2c79ac936ee5c19ac857f25. All that's missing is serializing constraints, which shouldn't be too difficult to implement: - It should be emitted as part of the `Validate`...

Thinking about this a bit more. Our support for arbitrary `expr` in certain rules throws a wrench into this being a fully compile-time thing. If you have e.g. `length(min=1)`, then...

> I can't find any confirmation in README that it's supported and recommended way of accessing struct siblings. The `self.field` and `ctx.field` syntax is definitely part of the public API,...

The general solution _is_ `custom`. It doesn't always result in the most aesthetically pleasing solution, but you can use it to do pretty much anything you can think of. It...

I added an example to the README in https://github.com/jprochazk/garde/commit/5b80e50203dcc91de8ffc2608e91813878107e57, but I'm keeping this open for an `equals` rule.

Validating keys is not possible right now without custom validators, and the only way you can validate the values in a `HashMap` is via `#[garde(dive)]`, which is definitely easier now...

`garde` doesn't store or output the values anywhere for security reasons ([validator#157](https://www.github.com/Keats/validator/issues/157)). I think https://github.com/jprochazk/garde/issues/7 would definitely be the right solution to this. I'll add more context into that issue,...

> This is only relevant for a small fraction of use cases I'm not sure about that. I'd prefer to not have my validation library leak secrets by default, and...