> On Nov 30, 2017, at 3:54 PM, Xiaodi Wu <xiaodi...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
