Swift's type System

Poke at the final version of @swiftgg

Brent Simmons to solve the problem that is not present, as if the problem exists in the same way:

The type system of Swift solves a problem that I have not met.

I feel the same way about that, and I bet a lot of other objective-c developers will think the same thing.

When I first started trying to use Swift, the compiler seemed to do the right thing with me 1. But as I became more familiar with the language, things got better, but sometimes its strange error messages made me feel like a wayward child who was hard to please.

In such cases, the benefits of Swift's rigorous type checking will be less than the effort you have made to run the code. Even so, its type system grew last year to the extent that I never wanted to miss it.

Swift Better understand

Compared to objective-c I prefer Swift the biggest reason is not his type system, but some more mundane features

• A class of citizen value. It can be put integer struct in without the use object of packaging array , which can be said to be a big win, because it means that we can extend these types.
• Enumerates the associated values. There are also tuples. Building a data structure model in Swift becomes clearer.
• Pattern matching.
• Clearer syntax and no header files.

In short, Swift is a modern language, and objective-c is obviously not.

If Apple released the true "Objective-c 3.0" last year, modernizing 2 with the obj-c dynamic feature, I would be happier and would never argue for more static type checking. After all, "I know what I'm doing, and I'll never cause an error because the array contains unexpected types. ”

Hole-driven Development

But Apple gave us Swift, not objective-c 3.0. Swift's release prompted me to learn about other languages that have the same type of system, such as HASKELL,ML and Scala. The special thing I learned from those communities was hole-driven (or compiler-driven) development: Do not use the compiler as a force to confront you, but as an artifact that solves your problem, one step at a time, depending on the type.

Hole-driven Development is a fantastic technology to build data structure models and data transformations (Haskell and its peers are especially good at it), and despite the potential for improvement, it still behaves quite well in Swift. The most critical difference between the annoying compiler and the useful compiler is that its error message is not easy to understand, and many Swift diagnostic information is still quite mysterious 3.

For typical GUI programming, compiler-driven development may not be so useful, although I think this is largely rooted in the Cocoa API's design rather than the limitations inherent in compiling-driven development. Libraries like Reactivecocoa show us what kind of API the type system (to some degree should be clear syntax) is designed for. When you can rely on a compiler that is lucky enough to have a generic type of complex signal transformation, it is easier to ensure the correctness of the results. Now I find it much harder (and then harder to understand) to write such code in OBJECTIVE-C because I need to remember more in my mind.

Automatic documentation

Another great benefit of a strict type system is the automatic documentation generated as a byproduct. As a developer on the Apple platform, we don't have access to the source code of the libraries we use most often, so we need to rely on documentation. The more information the compiler forces the API designer to provide, the easier it is for people who use the API. The single optional comment provides a significant increase of 4 for COCOA documents. Imagine if all of the Cocoa API's method parameters and return value types are id . The header file is basically useless.

Summarize

After forcing myself to think very carefully about the type, I found that my Swift code was better designed and easier to maintain. I'm more confident about the correctness of my code, and what's even weirder: it's more fun to write! (PS: Here is a strong kidney pill advertising is the sense of vision)

Swift is still at its initial stage. Sometimes it may make you frustrated, but over time the compiler prompts you for a more user-friendly error message and can even make your code more reasonable. For example, we are all entangled in an example, concurrency: If the compiler can still drop proof that your multithreaded code does not conflict, that is a huge advantage. Swift can't do it yet, but Rust can. I'm quite excited about the times.

1. This is one of the reasons why I feel Swift's decisiveness is not an easy-to-learn (Yixi) language. The other is a complex standard library.

2. We have been using "objective-c without C" for decades, but in the form of Smalltalk

3. There is no doubt that at least part of the reason is that I am unfamiliar with language

4. I need to remind you that annotations are not guaranteed to be correct, so strictly speaking they do not have the header file comments reliable. One might think that just a strict compiler can force Apple's documents to be more accurate.

Swift's type System