nestedContainer in KeyedEncodingContainer and UnkeyedEncodingContainer should be throwing

[itaiferber]

@ahti

I'm not so sure about this. I can imagine many reasons why a format could support, for example, limited nesting, size limits, only nesting under specific keys and so on.

Could potentially, yes — but are there common formats which do, and in a way which necessarily require throwing on a container request?

Note that it is not our intent to be able to represent all possible serialization formats and their limitations. From another thread:

@itaiferber

But yes, if you have a format which is truly incompatible with this model, then it might not be well-suited to fit the Codable API. This is a tradeoff we made in the design: if you try to capture something representative of all serialization formats, you end up with very weak and vague API because there are ends of the spectrum which don’t align with one another at all. But I would say that ~90% of serialization formats are extremely similar to one another and can be captured well here.

It's possible to come up with formats which put such strong limitations on encoding, but I'm not sure how well they would fit the Codable model otherwise.

@ahti

My solution would be good for that if it were not significant to only request a container and then do nothing with it, but a common type (Array) will request an unkeyed container and then do nothing with it when empty, which should definitely lead to an empty array in the case of JSON. Thus my solution alone does not address this problem completely, requiring another workaround somewhere.

I'm not sure this problem is significant enough to warrant a change right now (can't think of a way to do it without breaking source compatibility without compiler magic right now), but I do think it is a weak-point of the current design.

Indeed, the representation of Array cannot change, but that is to our benefit because we can rely on it not doing anything special. If you wish to allow Array and Dictionary to encode empty containers (while other containers become no-ops): both of those cases fall into encode<T : Encodable>(_: T...), wherein you can check whether the object is an empty array or dictionary and store [:] or [] directly instead of asking them to encode.