nestedContainer in KeyedEncodingContainer and UnkeyedEncodingContainer should be throwing

[tonyfreeman (Deleted Account)]

@cherrywoods

I’m not sure if this is what you mean with Encodable errors

Errors from custom Encodable implementations.

@cherrywoods

using e.g. JSONEncoder you do not directly know where the error comes from because it is passed from one encode(to:) implementation to the next via the method calls inside the encoder

This is an implementation detal; and JSONEncoder can store this path without protocol requirement. What the use of it inside custom Encodable implementation? (Since we already have EncodingError.Context.codingPath)

@cherrywoods

I don’t think this is a hack, I got it from there:
It at least works better IMO, because this is an internal name and there is no guarantee that it won’t change.

But again, this is about Foundation and its hidden implementation, not about Codable itself. My Coders are public and I found useful to call .encode(to: ) or type.init(from: ) directly.

[cherrywoods]

@tonyfreeman

EncodingError.Context.codingPath

That was what I meant, it is of course an implementation detail of encoder how you get it. I suppose it is meant to facilitate the same as property on encoder, so that an encoding instance can see where it is in the encoding hierarchy. I guess @itaiferber knows the real reason.

@tonyfreeman

But again, this is about Foundation and its hidden implementation, not about Codable itself. My Coders are public and I found useful to call .encode(to: ) or type.init(from: ) directly.

This might apply for your usage, but just not for any encoder. This kind of thing is required for those purposes in more closed environments and especially if you wan't to use multiple encoders from multiple sources/it's just a unified way to do it.