> 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. :-)

swift-evolution mailing list

Reply via email to