On Nov 15, 2017, at 1:38 AM, Andrew Thompson via swift-evolution
<swift-evolution@swift.org> wrote:
> Hi Chris,
>
> There are only a few examples in the proposal that demonstrate using dynamic
> member lookup.
>
> I suppose that some examples will look like this:
>
> let foo: PyRef = ...
> foo.bar // translates into foo[dynamic: “bar”]
> foo.bar.baz // translates into foo[dynamic: “bar”][dynamic: “baz”]
>
> and if we have:
>
> extension PyRef {
> var one: Int {
> return 1
> }
> }
>
> foo.bar.one // returns 1, because it translates into foo[dynamic: “bar”].one
>
> This to me is hinting that dynamic member lookup will only be applied to one
> property at a time. In order for it to work on multiple levels, the type
> being returned by the subscript operation must still conform to
> DynamicMemberLookup. Is this how you envisioned it to work?
The author of the type gets to make that choice. In the case of the Python
interop, yes, it will return another PyRef. In the case of a JSON library,
that should also return "Self?" so that you can optional chain through an
access path.
That said, there are other potential use cases where you may only want a single
level of dynamism. The proposal allows the API author to specify the element
type, which means they have flexibility to do what is right for their usecase.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
