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

[Chris Lattner]

> On Nov 30, 2017, at 3:54 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> While we shouldn’t necessarily avoid a feature simply because it can be used distastefully, consider something like this:
> 
> 	public extension NSObject :  DynamicMemberLookupProtocol, DynamicCallableProtocol { … }
> 
> that goes directly to the Objective-C runtime to resolve member lookups and calls—avoiding @objc, bridging headers, and so on. It’s almost frighteningly convenient, and one could imagine some mixed Objective-C/Swift code bases where this would save a lot of typing (of code)… at the cost of losing static typing in the language. The presence of that one extension means I can no longer rely on the safety guarantees Swift normally provides, for any project that imports that extension and uses a subclass of NSObject. At best, we as a community decide “don’t do that”; at worse, some nontrivial fraction of the community decides that the benefits outweigh the costs (for this type or some other), and we can no longer say that Swift is a strong statically-typed language without adding “unless you’re using something that adopts DynamicMemberLookupProtocol”.
> 
> I agree that the prospect above seems not ideal at all. On reading Chris's proposal, it never occurred to me that the intention was to support such retroactive conformance to these special protocols. Admittedly, such retroactive conformance is possible with all protocols--with the notable exception of those that require compiler synthesis of requirements. But Chris's protocols seemed magical enough (in the gut feeling sense) that I naturally assumed that retroactive conformance was never on the table. We would be justified in making that prohibition here, I think, although I'm not sure if Chris as proposal author feels the same way.

FWIW, if retroactive conformance itself is a concern, then I’d be perfectly fine restricting the proposal a bit, and just say that DynamicMemberLookup has to be declared on a *primary type declaration* and not an extension.  That seems perfectly reasonable, and I agree that “Dynamic behavior” could be considered part of the primary behavior of a type that shouldn't be retroactively added.

> Alternatively--and perhaps more elegantly--we could address this concern head-on by having, instead of `DynamicMemberLookupProtocol` and `DynamicCallable`, a magical class `DynamicObject` which all dynamic types must inherit from. It would then be clear by design that Swift types cannot be _retroactively dynamic_ in the sense that Chris proposes. I *think* the vast majority of bridged use cases can tolerate being `final class` types instead of `struct` types. I could be wrong though.

I’d really like to use this thing with structs, so it seems better to limit it to primary declarations to solve this concern.

> As Chris writes in his proposal, there are several areas (such as data science) where, to put it plainly, Python or another dynamic language is significantly better than Swift due to a much larger ecosystem of libraries, tools, and user communities, with sometimes decades of lead time. It is nonsensical to talk about how Swift is "supposed to be better" in any way whatsoever in that context. As diehard Swift users, we may be confident that the virtues of Swift's syntax, static typing, compiler smarts, protocol-based design, or whatever else offer opportunities for, say, data science libraries and tools to be better in the future, eventually. But to make this even possible involves first making Swift a viable language in which to work with current data science tools. Y

This is a really great summary - and an example of the challenge of swift-evolution, whose members far over-represent “current” swift users, and far under-represents “future” ones. :-)

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171130/2f144030/attachment.html>