SE-0489 followup: formatting EncodingError and DecodingError's debug descriptions

Development Standard Library
,
14

I’m wary to commit to supporting any particular format:

  • It could add additional punctuation that would be at odds with the main goal of this proposal (readability for debugging). I’d prefer not to have newer developers puzzling over extra syntax if it’s avoidable.
  • If we commit to, say, jq format, we’d surely be signing up the maintainers of the stdlib for future bug reports if people find issues where our formatter is out of spec or has an edge case. I’m hoping this PR is a low-maintenance way to make these types more usable in the general case.
  • Which format would we pick? Maybe jq is an obvious pick, but it’s not universal, and Codable is used by many formats that aren’t JSON.

That said, I love the idea of having options for various path formats, and I have a few thoughts:

  1. I encourage you to discuss error formatting in this thread: The future of serialization & deserialization APIs
  2. If you have a particular format that would be useful for debugging in your own code base, don’t wait for the standard library to add it! You have all the information you need in the CodingKey protocol’s public requirements to build your own formatter. Then you could write an extension EncodingError and DecodingError in your own project that would let you run (lldb) po someError.jq to get the jq formatted version, for example.
  3. Building on the above, I could see such a utility being built as a Swift package that allowed others to contribute handy formatting implementations, either to the main code base of the package, or as in-app conformances to a protocol provided by the library.