Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the [0.10.0] release we introduced a new
Decoder#ensure
method that was semantically kind of weird and included some behavior that (when used together with error accumulation) was definitely buggy:Thanks to @ylaurent for noticing and reporting this.
The tests would have caught this bug, but the relevant test was itself buggy, containing a check for oddness that said e.g.
-1
was not odd.I've changed the documentation for the previous version of
ensure
to state explicitly thatdec.ensure(p1, "p1").ensure(p2, "p2")
will only provide the first failure, and have added a new, more powerfulensure
method that allows the user to provide multiple errors that depend on the decoded value.@pfcoperez, I was thinking we might be able to add a similar
HCursor => List[String]
variant forvalidate
that would accommodate the use case supported by your #1020, and that would keep these two methods consistent. What do you think?