This is my first screencast! I had a lot of fun making it, and I hope you enjoy it.
One of my favorite parts of Swift is the optional concept, which separates variables which are never null from variables that can sometimes be null. This helps prevent errors from trying to use objects that don't exist. The syntax involves `!` and `?` which can make your code seem excited and confused, but it's definitely a step toward making your code safer!
For example, say you have a UI element that might have a label. If indeed it has a label, and you wanted to set the color of it to red, you can store your label like this:
`var label: UILabel?`
which signals that it may not exist. Then to set the color, you would do this:
`label?.textColor = UIColor.redColor()`
The question mark says if it isn't there, then don't assign the new color. We don't need to check the case where the label does not exist because Swift automatically does it for us!
While I do not have time to go over the whole video, surely you could have come up with much more serious reasons why Swift might be preferable to Objective C than "uhm, it has no namespaces and looks strange". Also, there were no reasons why "not to use Swift [yet]", making sure to mention the terrible state the developer tools are at this point, as well as many many missing language features and other quirks which make it a language not yet ready, in my experienced opinion, for large projects, or when some C/C++ operability is required.
>making sure to mention the terrible state the developer tools are at this point
Terrible compared to something like a mature IDE like Visual Studio or Eclipse and/or an established toolchain.
Because compared to what most newcomer/not top-10 languages have (languages like D, Racket, Haskell and beyond) it's extremely impressive, especially considering the language is so young.
No, I mean terrible compared to the Objective C/C/C++ Xcode toolchain, normally used where Swift may come in the picture. It needs at least one more year of development and design.
Swift's Optional is just Maybe with some built-in sugar. Sum types are supported, with the caveat that the compiler is sort of broken when it comes to generics.
Personally, I just want higher-kinded types, and for the following code snippets to work as-is:
enum Either<A,B> {
case Left(A)
case Right(B)
}
enum Tree<A> {
case Leaf
case Node(Tree<A>, A, Tree<A>)
}
The first breaks because of the "Unimplemented non-fixed multi-payload enum layout" compiler error, and the second breaks because enums have value semantics. Both can be worked around in full generality by declaring a 'Box<T>' generic wrapper class, but that workaround is inelegant and cumbersome.
I agree! Eithers are cool, too. What I'm really excited about is that these sorts of concepts are starting to find their way into languages like Swift. Getting built-in support for Eithers would be super awesome.
In the meantime, you can vaguely simulate it with named tuples.
let response = (error: "Could not connect to server", success: false)
It's not quite the same, but at least there's an easy way to bundle your data together.
edit: I like Someone's suggestion to use and discussion about using enums as union types below.
enum Barcode {
case UPCA(Int, Int, Int, Int)
case QRCode(String)
}
This can be read as:
“Define an enumeration type called Barcode, which can take either a value of UPCA with an associated value of type (Int, Int, Int, Int), or a value of QRCode with an associated value of type String.”
So, you can do
enum ResultOrError {
case Result(ReturnValue)
case Error(int,String)
}
Unfortunately, enums and generics do not mix, AFAIK, so it looks clumsy.
I think the reason for the special syntax of '?.' is that the designers think it is a very common case, at least in Swift programs.
And yes, I would like to see a better syntax for that, too. A generalization of C's short-hand 'if'
Enums and generics mix just fine in theory. Rust is a good example of this, with the `Result<T,E>` type. But at the moment in Swift if you try this you get "error: unimplemented IR generation feature non-fixed multi-payload enum layout". Presumably this will be supported at some point.
That was great. Didn't think that Id watch the whole thing, but now I want to see more. She put on an awesome presentation and the REPL worked really well in this format. Thank you for putting this together and please do more (if you have the time, of course).
One of the things I find really interesting about Swift is that you can execute uncompiled Swift files as shell scripts, similar to how you can with Rust.
One of my favorite parts of Swift is the optional concept, which separates variables which are never null from variables that can sometimes be null. This helps prevent errors from trying to use objects that don't exist. The syntax involves `!` and `?` which can make your code seem excited and confused, but it's definitely a step toward making your code safer!
For example, say you have a UI element that might have a label. If indeed it has a label, and you wanted to set the color of it to red, you can store your label like this:
`var label: UILabel?`
which signals that it may not exist. Then to set the color, you would do this:
`label?.textColor = UIColor.redColor()`
The question mark says if it isn't there, then don't assign the new color. We don't need to check the case where the label does not exist because Swift automatically does it for us!