Codec.custom and Codec.object: Warning about order being important #21
Description
When first using this library, I have not made the realization that codecs will likely have a similar issue like JSON decoders in that order of fields is important and can't be checked/secured against in compile time.
I've introduced a bug by using codecs wrong - adding a new parameter to the function passed Codec.custom in the 1st position, while adding another |> Codec.variant0 line in a non-1st position.
Might be useful to have a warning / note about order still being important in Codec.custom and Codec.object and what bugs can happen when you mix those up.
And perhaps about Codec.enum existing. There will be people like me whose first encounter with elm-codec is via elm-review-derive which doesn't do Codec.enum