Swift: Drop the strict type system, follow Strongtalk instead

Originator:christoffer
Number:rdar://17340748 Date Originated:
Status:Closed Resolved:Won't fix
Product:Developer Tools Product Version:Version 6.0 (6A215l)
Classification: Reproducible:Always
 
I realize that it's a vain hope that this bug report will be anything than summarily dismissed, but I feel I have to make the attempt nonetheless.

Please reconsider Swift’s basic philosophy of fundamentally static typing. Although it is possible to gain access to dynamic dispatch by way of @objc or extending NSObject, the very form of these annotations hint at dynamic dispatch as a second class citizen in Swift.

Of course, it’s not always necessary to be dynamic, and writing in a safer and more expressive form of a low level language than C and C++ is very nice indeed.

It’s tempting to suggest three levels of classes/structs, starting with the current Swift struct and class, then adding a third dynamic class. However, we then run into difficulties with generics over all of these different types.

The current state of generics in Swift today is poor. It doesn’t have a very expressive system of generics, which makes it hard to work with certain structures, and seriously hampers reuse. One solution would be to move towards Scala/Haskell/Ceylon with a much more expressive set of generics. However, in those languages the generics goes hand in hand with their programming paradigms. For an imperative language, the gain is not as high, and the added complexity of a generics system like that (which form a sub language in itself) works against the intended simplicity and clarity of the language.

Right now Swift’s generics are directly responsible for making things that were easy in ObjC really hard.

In addition to generics, please also note that functions/closures is not a complete replacement for selectors. Aside from the added cognitive load debugging closures (since the location of calling the closure is quite different from where it was created), it requires lots of work in order to do things like assembling an UI from a configuration file.

My conclusion is that dynamic dispatch must be a first class citizen in order to make Swift suitable for UI programming. Also, the generics must be much simplified and permissive in order to not obstruct and complicate the day-to-day programming work. With a dynamic dispatch as its base, programmers could mix and match generic and non-generic code, statically typed with dynamic. As an example, look at Strongtalk.

If necessary, project an Objective-Swift with Swift forming the base of a dynamic language, like C forms the base of Objective-C.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!