SE-0195 — Introduce User-defined "Dynamic Member Lookup" Types

[tkremenek (Ted Kremenek)]

Proposal Accepted

On February 8, 2018 the Core Team decided to accept this proposal, given the form in its second version where an attribute is used to designate types that participate in the sugared dot-syntax described in this proposal.

After reviewing the feedback from the community, the Core Team felt the spelling of the attribute should remain as proposed — @dynamicMemberLookup. The alternative of @dynamic(...) was also considered, but the Core Team felt that spelling to be too close to the dynamic keyword and a potential source of confusion. This concern was brought up in the review thread as well.

The rationale for the marker being an attribute instead of a protocol (as in the original proposal) was well-articulated by @Chris_Lattner3 in the review thread in that the marker protocol would not provide the expected affordances of a normal protocol:

@Chris_Lattner3

We debated this at length in the core team meeting, and my interpretation of the discussion was “yes, this could be modeled as a protocol” but “this would mislead people”. The problem is that being a protocol would naturally lead people to think that they could use it (e.g.) as a generic constraint, but the underlying model does not support that. If we provided it as a protocol, people would see it as a deficiency that the implementation didn’t support that and that they would keep asking for it. Given the implementation approach, these approaches would be “wrong”, but they wouldn’t be wrong for asking, given how protocols fit into Swift.

Thank you to everyone who participated in discussing this language change, both during the pitch phase and the formal review!