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

Mike Kluev mike.kluev at gmail.com
Fri Dec 1 04:24:32 CST 2017

on Date: Thu, 30 Nov 2017 17:54:19 -0600 Xiaodi Wu <xiaodi.wu at gmail.com>

> 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.
> Now, as to the possibility of failure: I agree also that eliding the
> possibility of lookup failure at the callsite requires further
> consideration. Some might agree that restricting dynamic features only to
> subclasses of a `DynamicObject` might be clear enough that we do not need
> to go further in this regard.

this might be a good compromise indeed. along with PythonObject subclass,
RubyObject subclass, etc. and eventually even "backporting" NSObject to be
a subclass of DynamicObject and using this same infrastructure.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171201/45882cd6/attachment.html>

More information about the swift-evolution mailing list