I added a failing test as first commit to demonstrate the problem, which reveals a little flaw in the current design.
Long story short, we shouldn't decode while encoding and the other way around, and we should treat types that encode to array-likes as codecs to 'Encoding [] pretty much the same way we treat dictionaries-like as PropertyList<'Encoding>.
This new iteration in the design affect a bit the error DU and as seen in the legacy version of count it proves we're on the right track, as it becomes type safer.
It also reduce the amount of methods in the interface, by assuming tuples (and unit) will encode in an array-like way.
I added a failing test as first commit to demonstrate the problem, which reveals a little flaw in the current design.
Long story short, we shouldn't decode while encoding and the other way around, and we should treat types that encode to array-likes as codecs to
'Encoding []
pretty much the same way we treat dictionaries-like asPropertyList<'Encoding>
.This new iteration in the design affect a bit the error DU and as seen in the legacy version of
count
it proves we're on the right track, as it becomes type safer.It also reduce the amount of methods in the interface, by assuming tuples (and unit) will encode in an array-like way.