search

apple / swift-distributed-tracing-extras

Apache License 2.0
32 stars 3 forks source link

Consider macros to generate Code instead of using @dynamicMemberLookup #33

Open fabianfett opened 1 year ago

fabianfett commented 1 year ago

We should investigate, if there is a chance to generate the needed code to allow dot property access using macros instead of using @dynamicMemberLookup.

Potentially relevant swift proposal: https://github.com/apple/swift-evolution/blob/main/proposals/0389-attached-macros.md#member-macros

ktoso commented 1 year ago

Thanks for the issue! It's worth having a look but I'm skeptical that macros "win" us much here.

If we really needed to, we can swallow the boilerplate and write it out all once rather than take the macro expansion compile time hit in all dependent projects. I'm not sure we'd be really saving a lot of typing either tbh, everything needs an identifier, type and name, and the current way is pretty efficient in that.

The "dynamic lookup" was purposefully written in a way that should be optimized well; so it is not that it is actually entirely dynamic -- before jumping to conclusions on that we should also benchmark against "raw" implemented optimal stuff to see if it's worth it. If it is, I think compiler team would consider this a bug, tbh.

slashmo commented 1 year ago

This is an interesting idea. For me, the question would be if we could still add "niceties" such as the Operation type here to be used as the key instead of a plain String:

https://github.com/apple/swift-distributed-tracing-extras/blob/6906d6b7eaf86847231c54fd2163a87a78f51ace/Sources/TracingOpenTelemetrySemanticConventions/SpanAttributes%2BFaaSSemantics.swift#L123

It's unique to this implementation of semantic attributes and is one of the benefits of not generating them. I also purposefully rewrote some attributes' documentation to make more sense in Swift and omitted a couple of unnecessary attributes, e.g., JVM-specific ones.