I think this sounds like a good change. However, I’m not sure I fully understand how it affects our ability to extend the API in the future.
Future proposals can add new fields to
LogEventwith sensible defaults — a richer metadata type, or an attachedError(as a follow-up for SLG-0003 proposal) — without touching theLogHandlerprotocol and without requiring any changes to existing handler implementations. This is the primary motivation for this proposal.The SLG-0004 proposal introduces an
AttributedMetadatatype that wrapsLogger.Metadatawith additional context. Adding it toLogEventas a new optional field would be source-compatible, and the existingmetadatafield could become a computed property that projects fromattributedMetadatawhen present, keeping old handlers fully functional without modification.
From your second example, I take it that we want old handlers to get a computed metadata with both “regular” and attributed metadata merged. But an updated LogHandler that handles the new attributedMetadata would want metadata to return nil if info(message:attributedMetada:...) was called, right? Otherwise they would need to first check attributedMetadata and only if that is nil, check metadata.
And for the error attribute in SLG-0003, we are considering adding a default serialization for old LogHandlers, but this should of course not be done for updated LogHandlers. How would such a fallback be implemented using LogEvent?