I have some thoughts:

1. I’m not sure if it’s more appropriate to add extension methods, or modify the existing methods to take an Error? that defaults to nil, i.e. func log(…, error: Error? = nil, …)
2. Concerning the serialization:
   1. Is there reason to add ”error.*” as part of the API (to future proof/discourage other usage) or only ”error.message" and ”error.type”
   2. Is it more sensible to serialize as [”error.message”: …, “error.type”: ...], or [”error”: [“message”: …, “type”: …]]

@samuelmurray

1. I’m not sure if it’s more appropriate to add extension methods, or modify the existing methods to take an Error? that defaults to nil, i.e. func log(…, error: Error? = nil, …)

Please, keep them as separate methods. Changing the method signature is strictly speaking an API breakage, even if default value keeps code compilable.

2. Concerning the serialization:

   1. Is there reason to add ”error.*” as part of the API (to future proof/discourage other usage) or only ”error.message" and ”error.type”
   2. Is it more sensible to serialize as [”error.message”: …, “error.type”: ...], or [”error”: [“message”: …, “type”: …]]

error.message and error.type are easier to communicate as the API surface. I am not quite sure about the performance implications of parsing extra nested json vs parsing dot-separated keys in the external systems, might be a good question for the broader audience during the review, but worst case scenario a Log Handler specific for an intake system that cares can combine construct nested dicts, while we keep the API smaller.

Thank you for taking time to prepare the proposal! I have left a few suggestions and a few questions to discuss before starting the formal review process.

@kukushechkin thanks for all your suggestions, really appreciate the help!

@samuelmurray thank you for addressing the comments! The proposal looks good for the public review now. Let's wait until the Monday for any more suggestion, and if none arise, I will merge this and start the formal review at https://forums.swift.org.

@samuelmurray thank you for addressing the comments! The proposal looks good for the public review now. Let's wait until the Monday for any more suggestion, and if none arise, I will merge this and start the formal review at https://forums.swift.org.

The post: https://forums.swift.org/t/proposal-slg-0003-standardized-error-metadata-via-logger-convenience/84518