Introduce “Dynamic Member” fulfillment of Protocols

FWIW, just explaining thought process here:

This was suggested and I specifically considered this and pushed back on this during the review process. The entire point of the dynamic member lookup feature is to allow unbound syntactic extension of a member lookup in the case when the author of a type cannot enumerate all of the members that a user might want to use statically.

In the case of protocol conformance, a protocol does have a specific static list of members that need to be satisfied. While the @dynamicMemberLookup proposal could be extended to provide implementations of this fixed and static list of members, doing so would be merely be a syntax sugar extension to benefit specific narrow protocol conformances -- it would not benefit general users of the concrete type. It also doesn't (IMO) provide enough benefit to be worth the compiler complexity that it would produce, in terms of generated thunks.

I agree that this is something we "could" do, but as others have asked for, I'd love to see evidence of specific reasons we "should" do this. Those reasons should balance the cost and the benefit of providing such a feature.

-Chris

6 Likes