Relatively up-front, we made the decision that very little of the Encoder/Decoder API would be optional — this is why, for instance, encoding container methods like container(keyedBy:)/unkeyedContainer()/singleValueContainer() don't throw: if you don't support all types of containers in one way or another, your format is likely sufficiently different from what Codable offers that it likely isn't a good fit for the infrastructure.
Sometimes this means that some encoders to some formats might need to do additional work to offer compatibility with Codable features — this might mean a format that doesn't natively support dictionaries would instead encode key-value pairs, or that a format like XDR (which offers no identifying tokens) would need to insert breadcrumbs to indicate some amount of type information. [I don't know enough about XDR to know whether this is feasible; I suspect that the answer is "no", but it's entirely possible that XDR, for instance, is not a good fit for `Codable`]
In general, contrary to @gwendal.roue's suggestion, I would say that fatalError is rarely the right answer — instead, encoders should do extra work to accommodate differences between the runtime representation and the encoded representation of their values. (The specifics of this vary by format, but that has always been our intention, at least. Nothing prevents you from fatalErroring, though.)
In this case at least, a default implementation should be reasonably possible.