The `Solo` instance is incorrect

[Qqwy]

Solo is the canonical 1-element tuple type.
However, the implementation added in PR #891 treat it as any other normal 1-element type, which is incorrect.

This becomes problematic when you have code that wants to seriaize/deserialize generically over tuples of various arities:

• (10, 20, 30) <-> "[10, 20, 30]"
• (10, 20) <-> "[10, 20]"
• Solo 10 <-> "10" ❗❗❗
• () <-> "[]"

[sjshuck]

I think "incorrect" is a bit strong but the argument is reasonable. The problem is it would break 4+ years' behavior. I'd be curious to see

code that wants to seriaize/deserialize generically over tuples of various arities

because I suspect a custom datatype implementing a subset of HList functionality would better serve, or demonstrate that genericity isn't worth the trouble, depending on the genericity desired.

[Qqwy]

You're absolutely astute that this change would be backwards-incompatible and thus could only be introduced in a breaking PVP release. That of course shouldn't be done lightly, and this issue by itself by no means is enough to warrant such a breaking change in and of itself. But if there is another change that needs a breaking version release, this problem could be resolved at the same time.

---

What I ended up doing in the codebase where I first encountered this, is creating a separate datatype called Single that functions as Solo.

Repo here, details of encoding/decoding tuples here.

Indeed, creating a Tuple-like custom type like HList would be another solution.