I could add a config option there, to choose between fallback handling or throwing an exception.
Laravel way, the fallback seems acceptable, however in cases we want to explicit enforce a specific cast, usually we want to validate and fail.

Would you like an addition like this?

I'm proposing separating the casting and serialization steps. That way you can cast or validate any value into any format, and only after this will the appropriate serializer be selected automatically based on the resulting format, so there shouldn't be any conflicts.

I have in mind two different cases:

• Let's consider we want a meta value to be always string. So we have two choices:

  • to validate and parse the input before use setMeta ( I think this is your suggestion), and after this, Handlers will do their stuff
  • to use the already existing Handlers that do the same job but force a specific one, and as an extra step, before parse the value to use canHandleValue for validation. Laravel DataCasters are doing a similar job. They just try to parse, and worst case scenario they throw an error

• Second scenario is that we have:

  • a meta instance, we fill it with an array of integers array<int>
  • another that we put an array of strings `array
  • and a last one, we put an array of objects array<stdObject>
    Already we have the Handlers that try to parse the given value, and we can register new ones.
    However, the first parser which may be able to parse a value, will handle it, so the parsing is left in luck for more complex structures, and depends on only of the handlers sorting. (Ex: Collections of different models)

On both cases, with the existing functionality, each value needs to be parsed twice.

PS: Next Major version, Handlers could implement Castable (edited)