[swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Michel Fortin michel.fortin at michelf.ca
Mon Nov 20 21:15:13 CST 2017

> Le 20 nov. 2017 à 21:22, Chris Lattner <sabre at nondot.org> a écrit :
>> On Nov 16, 2017, at 4:49 AM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
>> I think this protocol and its subscript need a better name. From a user of the class point of view, the subscript looks like you can retrieve the members of the class, whereas in reality you'll only get the ones you have manually implemented. Even methods and properties having the `dynamic` attribute won't be available, even though the subscript name would suggest that.
>> I would propose adding the word `supplemental`to the subscript name and the name of the protocol to make it clearer that this is only for adding members that are not declared in the class (including the `dynamic` ones).
>> As in `SupplementalDynamicMemberLookupProtocol` and `supplementalDynamicMember` for the subscript.
> I’m totally open to suggestions for a better name, but I don’t see what “Supplemental” is adding here.  Recall that this protocol is compiler “magic” that is part of an implementation of a type, it isn’t really part of the user-exposed API of the type.  I wouldn’t expect a user to ever write:
>    pyVal[dynamicMember: “foo”]
> Even though they could.

I'm not sure why you say it's not part of the user-exposed API. The type conforms to the protocol, and the protocol has this subscript, and there is nothing preventing someone from using it. And if for some reason you have the name of the member in a string variable and want to use it, you *have to* use it to get to the variable. So it'll definitely get used.

Perhaps supplemental isn't the right word, but I wanted to convey that it supplements the Swift-defined methods and does not shadow them. For instance, in your PyVal protocol type there's a member `ownedPyObject` that won't be accessible with `dynamicMember` but will be dispatched through the protocol witness table.

> Maybe we need to add private conformances to Swift or something :-)

Maybe, but that's not part of the proposal. :-)

Michel Fortin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171120/85e5658d/attachment.html>

More information about the swift-evolution mailing list