I think iff we added support for list values as well as dictionary values it would cover my use cases — at least from a JSON ecosystem perspective. (Numeric typing information is not a great loss when strings are the most reliable way to roundtrip numbers in JSON anyway.)
But I am a bit worried about how much boilerplate code might be needed to take an existing complex object like an event that already implements Codable and convert it to MetadataValue, just for it to get transcoded to JSON behind the logging interface. Maybe we could provide a MetadataEncoder to convert Codable implementations into MetadataValue instances?
No, not really. You would literally just write the bytes to the log file (and possibly flush) in the log function. As I said above we’ll provide a one-time initialiser which would be a good place to open the file.
Good question! That’s just a cheap way to get a namespace. Enums without any cases can’t be initialised so it’s really just a namespace enum Foo { static func bar() { ... } } gives you a function Foo.bar. I did that so it seems like three different example programs, each having a main function. Does that make sense?
Seems I missed to reply here over the break, sorry
Yes, that's the case.
I'm populating the logger with many things before it gets exposed to the user, some of which are "expensive" to render – those I want to put in there as .lazy. If they never log anything, that rendering pentalty should not be paid by anyone.
First of all: I hope everybody had a good break. And thanks very much for all the great feedback, @tomerd, myself and others are now busy integration all the feedback into a second revision of this proposal. As soon as we're ready, I will post a second thread which will give people the chance to comment on the revised proposal.
If you have more feedback, don't hesitate to post it over here though.
