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

Nevin · February 9, 2018, 4:53pm

If we are going to allow variables to be callable, I think it should be independent of and orthogonal to dynamism.

If square-bracket subscript syntax is good enough for native Swift types to imitate being callable, then it is good enough for imported dynamic types as well. And if that syntax is *not* good enough for imported types, then it is not good enough for native types either.

Chris_Lattner3 · February 9, 2018, 6:19pm

Lets discuss DynamicCallable on its own thread when the topic comes up. Thanks.

Chris_Lattner3 · February 12, 2018, 5:18am

I submitted an updated patch in PR14546. Thanks all!

Jon_Shier · February 18, 2018, 3:46am

If we ever get throwable properties, can this feature evolve to be implemented in such a way? That would make this feature more readable (try some.dynamic.property.chain vs. some?.dynamic?.property?.chain), far safer, and able to express proper errors. Frankly, I would gladly have traded the cleanness of property access for being able to throw errors now with try some().dynamic().property().chain(), but I guess that ship has sailed.

Also, as an aside, can the proposal be updated to reflect current Swift styling? It may be confusing to some if proposals don't reflect best practices in regards to recommended style (i.e. lower case enum cases).

Chris_Lattner3 · February 18, 2018, 9:10pm

Yes, this should compose directly and properly with throwing subscripts. I don't anticipate any problem with that, given that (at the end of the day) this is a syntactic sugar for existing underlying mechanics. Those mechanics define the semantics.

Chris_Lattner3 · February 18, 2018, 9:10pm

For anyone not following commits closely, FYI, the patch landed. We have @dynamicMemberLookup (including keypath support) in master now.

pvieito · February 18, 2018, 10:15pm

Great, thank you! Do you have an updated version of the PythonGlue.swift playground supporting the new attribute?

I would love to start playing with this :)

Daniel_Mullenborn · February 18, 2018, 10:39pm

I have just installed the swift-DEVELOPMENT-SNAPSHOT-2018-02-17-a, the DynamicMemberLookup works.
Surprisingly, the compiler still produces the error message.
"Unknown attribute dynamicMemberLookup"

dicklacara · May 2, 2018, 6:58pm

tkremenek:

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?

Great!

Is the problem being addressed significant enough to warrant a change to Swift?

Yes!

Does this proposal fit well with the feel and direction of Swift?

One to rule them all!

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No experience!

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I just jumped in and started using it. Two weeks ago, Apple open-sourced FoundationDB... FDB has APIs in Python, Java, Ruby, Flow, Go -- but no [current or announced] Swift API.

I am learning FDB and want to experiment and prototype in a Swift playground.

I've been experimenting for a couple of days -- no prior experience with Python, so had to get up some speed on that -- learn enough Python so I could learn FDB.

Long story, short: The tutorial is great and was able to get FDB working in a Swift playground thru the Python glue.

Here's a short example:

XcodeScreenSnapz0122134×2598 920 KB

Thanks,

Thank you!

dicklacara · May 2, 2018, 7:13pm

FWIW, I mentioned this proposal in a thread that I started on the FDB site -- asking about Swift language support:

https://forums.foundationdb.org/t/swift-language-support/53/16

It's the most viewed by far -- even with likes by FDB founders... so it looks like there is a bit of interest!

Chris_Lattner3 · May 2, 2018, 9:02pm

Super cool, I hope that the .call(member:) stuff will improve soonishly. I'm happy to see that you're finding this work useful.

-Chris