I don't have much to add here beyond what's been discussed already, but some assorted thoughts/links:
- Lots of good background in the original PR and in the followup thread, which I think are worth reading
- Gut feeling: this is a problem mostly created by
JSONEncoderfor itself — I'm not sure how many other encoders allow key modification in this way. It may be entirely sufficient to confine the solution there- One thing to keep in mind is that the key encoding strategies currently allow for a
.customstrategy, which may not follow the same rules as the strategies one might have in mind. I don't know how often.customis used, but it is there
- One thing to keep in mind is that the key encoding strategies currently allow for a
- I think
allRawKeyscould work (and we may not need to deprecateallKeysif we can just offer the raw version), though adding it at this point would require giving it a default implementation to prevent source breakage- You could theoretically just have the property default to returning
allKeys, though it may be a trap to forget to implement it
- You could theoretically just have the property default to returning
I'd love to be able to solve some of the inconsistency here too — we may need some input from some Foundation folks if they have time to spend on the problem, especially if the solution is constrained to Foundation-specific code (e.g. altering the JSONEncoder/JSONDecoder strategies) instead of changing all containers. (It does appear that the new AttributedString decodable implementation uses allKeys for decoding containers of attributes, so they may have some thoughts about how changes here might affect the implementation.)