At the risk of repetition, the argument against this feature (as already described by @Jumhyn) is illustrated precisely by your point here:
After multiple rounds of discussion, even on this second and likely final review, there is no agreement on what the synthesized implementation should actually be. Based on the extensive discussion thus far and again illustrated by this comment, there has been no convergence on this question and, on the evidence, never will be.
Simply put, there is a broad appetite for some default synthesis of Codable
, but since no one agrees on what that should be, by construction, it cannot be said that there is appetite for any one default. And make no mistake: this is the only feature in question here, a single default. There is no mechanism as in Rust's Serde package to select one of a number of options.
Addressing the revisions on this review specifically:
I am very glad that this revision has adopted Serde's default; I think that speaks to the reasonableness of what is chosen, all things considered. I am worried about the choice of encoding non-payload cases as true
in part for implementation reasons and in divergence from Serde.
Having not used the Rust package in question: what is the default used by Serde for non-payload cases (and can we survey some other similar tools also) and are there non-implementation-specific reasons not to adopt such precedent here?
Overall though, I have to agree with @Jumhyn: I do not see evidence that there is broad consensus for any one synthesized conformance or any movement towards convergence.
Although I like the move towards a more precedented default by looking to Serde, I would also note that Serde's documentation of its corresponding feature almost immediately goes into discussion of overriding the default that it provides given its unsuitability in a variety of circumstances.
If we are to hold that library up as useful precedent, we ought to consider seriously that the absence of any obviously correct default pushed Serde to offer options for encoding which we do not contemplate here. I do not see reason to rush this now as opposed to when we can address the concern. It is not merely an additive future direction but quite fundamental to the question of a default if it will often need overriding.
Put another way, I am concerned that making the default easy but not making any tweaks similarly easy in the context of something that needs tweaking could turn out to be an anti-feature.