Consider macros to generate Code instead of using @dynamicMemberLookup

[fabianfett]

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]

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]

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:

swift-distributed-tracing-extras/Sources/TracingOpenTelemetrySemanticConventions/SpanAttributes+FaaSSemantics.swift

Line 123 in 6906d6b

public struct Operation: RawRepresentable, SpanAttributeConvertible {

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.