Use @validate before decoding phase

Thanks for the quick reply @adamw!

This approach would solve the problem, indeed. However, it would be more elegant if @validate could be used to also validate the enum.

What happens now is that with all of the validations used in for instance:

  @validate(Validator.derivedEnumeration[Currency])
  currency: Currency
  @validate(Validator.min(0))
  age: Int
  @validate(Validator.pattern("[0-9]+"))
  someNumber: String,

we get a nice aggregation of the incorrect values:

expected age to be greater than or equal to 0, but got -1,
expected someNumber to match: [0-9]+, but got: \"ABCD\"

But the validation error for the enum will not be in that message. If I understand correctly, the decoding will done before validation, and will produce a separate error.

This also makes me wonder what the use of Validator.derivedEnumeration[Currency] is, apart from documentation. It will be executed after Circe’s decoding, which already proves that the value sent by the user is one of the values of the enum.

So ideally, something like this would be the error message:

expected currency to be one of ["EUR", "USD"], but got "NZL",
expected age to be greater than or equal to 0, but got -1,
expected someNumber to match: [0-9]+, but got: \"ABCD\"