[swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

[Chris Lattner]

On Sep 26, 2016, at 1:29 PM, sergio via swift-evolution <swift-evolution at swift.org> wrote:
> HI all,
> 
> a debate has recently taken place within the Objective-C/Swift dev community concerning the lack in Swift of something “equivalent” to Objective-C runtime programming. When using Swift exclusively, there seems to be no easy equivalent for Cocoa fundamental design patterns such as the Responder Chain, NSUndoManager, KVC/KVO/Bindings — and in general for code that leverages Objective-C's dynamic features (i.e., runtime programming). 

Yep, many of us saw it.  Thank you for asking on swift-evolution, which is the proper place to discuss the future of Swift.

> According to some developers, dynamic features in Ocjective-C grant easy coding and high decoupling and there are concerns that Swift might make harder a number of common Objective-C tasks (e.g., by increasing boilerplate code, lowering readability, making high use of switch, etc.) and eventually increase development time.
> 
> In this context, is interesting to know how those concerns are viewed within the Swift dev community and how they could be tackled. 

This is just my personal opinion, not meant to represent that of the entire core team:

> 1.     Do you envision a more dynamic Swift? Should some level of dynamism be added at the language or framework level (e.g., to make dynamic dispatch or some form of message passing possible, while ruling out trickier features such as method swizzling and others) possible ? Should Swift be dynamic at all?

Yes, I personally think that adding “dynamic” features to Swift is absolutely essential.  That said, one of the things I’ve observed in the “blogger debate” that happened a few months ago is that everyone has different ideas of what “dynamic” means.  I don’t think that it is interesting to provide the “equivalent” features to Objective-C, but I do think it is important that Swift be able to solve the same sorts of problems (including your list of Responder Chain, NSUndoManager, KVC/KVO/Bindings, …) in an fluent/expressive way, even if it works differently.

In fact, one piece of this was the first candidate listed in the Swift 4 stage 2 goals, adding a reflection API:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
This included the statement: "The core team is committed to adding powerful dynamic features to Swift."


The primary reason that Swift currently lacks these features is simple prioritization.  It has unfortunately not been the highest priority to build, because we already have working systems for all of those in Cocoa, and things like source stability and binary stability (among other things) are more important to the Swift community in the moment.  As Swift evolves, they will bubble up in the priority list. 

I know that having a read/write data reflection API is the top of the list for many people, and having the ability to reflect on methods is also important for some patterns.  I look forward to the community having the bandwidth to properly design and debate these things, because I’m confident that there are good answers for these. 

That said, to be clear, this is definitely out of scope for Swift 4 Stage 1, which is our current mode.  We need to stay focused in the short term on the most pressing issues, which revolve around Source and ABI stability.

> 2.     What is the challenge of making a more dynamic Swift (or adding features to it to help solve the same kind of issues that are solved in ObjC through dynamism)? How could that be achieved without making Swift a less safe language? [e.g., reflection, macros, etc.]

It is a bit pedantic, but Swift isn’t a “safe" language: it is a “safe by default” language which gives you direct access to unsafe constructs when you explicitly ask for them (e.g. UnsafePointer).  

Regardless of that, I don’t see any conflict with adding reflective capabilities, and I don’t see how having them would present a safety problem.  I expect that they’d end up being somewhat different than the Objective-C analogues of these features, but that is true about everything else in Swift (e.g. method call syntax in the two languages is pretty different).

> 3.     Are you aware of any work that has been/is being done in Swift development (Swift 3/Swift 4) to make Swift more capable of addressing the above mentioned concerns?

The most relevant is the extensive work on data reflection metadata that was put into Swift 3.  It is key to enabling the Xcode 8 memory visualization / debugger feature, and is a fundamental building block for a data reflection API.  In fact, if I recall correctly, a 3rd party framework already build a custom data reflection API around this metadata already (Zewo?).

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160927/29081c4d/attachment.html>