Swift 1.2 and Xcode 6.3 beta(developer.apple.com)
developer.apple.com
Swift 1.2 and Xcode 6.3 beta
https://developer.apple.com/swift/blog/?id=22
15 comments
If this is actually going to work well - great news for bigger swift projects.
The compile time caused by this issue was making the development process really slow. We had to split the whole application into mini sub projects to make it bearable.
The compile time caused by this issue was making the development process really slow. We had to split the whole application into mini sub projects to make it bearable.
"The number of crashes in the swift-compiler-crashes project shrank -83 % with today's release of Xcode 6.3b. Thank you Swift engineers! :-)"
https://twitter.com/practicalswift/status/564921024782041088
https://github.com/practicalswift/swift-compiler-crashes/com...
https://twitter.com/practicalswift/status/564921024782041088
https://github.com/practicalswift/swift-compiler-crashes/com...
Awesome, the ability to unwrap multiple optionals on one line should be bolded, underlined and all caps at the top of this article. Seriously though, this is an everyday pain point that happens all the time when writing Swift. Glad Apple is listening to developer feedback on this stuff.
Translation for those unfamiliar with Swift: Swift has a relatively strong type system. If a variable in Swift can be null at any point, it must be explicitly declared so as part of its type (e.g. an integer that can be null has the type "Int?", an integer that cannot be null has the type "Int").
Swift has a way to 'unwrap' these optional values and do things with them if they exist. Prior to this release, unwrapping multiple optional things required a bunch of nested if statements. With this release, unwrapping multiple optional values can be done in one if statement.
Translation for those unfamiliar with Swift: Swift has a relatively strong type system. If a variable in Swift can be null at any point, it must be explicitly declared so as part of its type (e.g. an integer that can be null has the type "Int?", an integer that cannot be null has the type "Int").
Swift has a way to 'unwrap' these optional values and do things with them if they exist. Prior to this release, unwrapping multiple optional things required a bunch of nested if statements. With this release, unwrapping multiple optional values can be done in one if statement.
> Awesome, the ability to unwrap multiple optionals on one line should be bolded, underlined and all caps at the top of this article
This is why it's lame that Swift's optionals are a language feature and not an in-language implementation.
In Haskell, optionals are Monads, which means there is a function
You can also daisy-chain them together using >>=, a la
This is why it's lame that Swift's optionals are a language feature and not an in-language implementation.
In Haskell, optionals are Monads, which means there is a function
join :: m (m a) -> m a
You can also daisy-chain them together using >>=, a la
fail1 :: Maybe a
fail2 :: a -> Maybe b
result = fail1 >>= fail2
If let (and optionals in general) is my favorite Swift feature and has immediately made my code 10x more stable from the get-go. Glad to see it get expanded like this.
I'd like to see them expand it the way Rust did: Rust lifted `if let` from Swift (I believe) but made it a more general-purpose refutable pattern matcher, it's just one step below match and works with any enum type not just Option. So you can write:
enum Foo {
Bar,
Baz(i32),
Qux(f64)
}
if let Bar = item {
// do something
} else if let Baz(val) = other {
// do something with val
}
Swift borrowed "if let" from Rust, not the other way around.
"The if let construct is based on the precedent set by Swift,"
https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...
https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...
That's putting it a bit mildly. Speaking as the author of that RFC, Rust's "if let" would never have existed if it were not for Swift. When I saw Swift's "if let" I immediately knew I wanted it in Rust. I also generalized it to arbitrary patterns at that time, since Rust doesn't fetishize Option the way Swift fetishizes Optional.
I am glad to see Swift 1.2 expanding "if let" to multiple clauses. But I do wish it supported arbitrary values instead of just Optional.
I am glad to see Swift 1.2 expanding "if let" to multiple clauses. But I do wish it supported arbitrary values instead of just Optional.
Wow. Such a rapid feedback loop here. Thanks for sharing.
if-let is great. I don't know where it started (apparently upthread they say Rust and swift have been swapping the idea) but Clojure has had it since 2008.[0]
(if-let [name name-whose-value-is-possibly-null]
(something-to-do name))
C++98 (maybe earlier) has a similar feature:
if (mytype* p = find_or_null(blah))
foo(*p);
if (auto opt = find_or_none(blah))
foo(*opt);I imagine everything in Swift has been borrowed from another language. OCaml, Go, etc. I'd be more interested in other great language features that are missing from Swift that are in other "classic" languages like OCaml, for instance.
Why is "if let" preferable to generalized pattern matching?
It's not "preferable" in the sense that you should have if let and not pattern matching. In Rust (and probably in Swift) it builds upon (and maybe desugars to, not sure) pattern matching. `if let` tends to be shorter and more readable than a full-blown match with a single match branch or just match/fail. Chainable `if let` is also significantly more convenient when trying multiple alternatives (on different source variables) one after the other.
See the Rust RFC on the subject for motivations and comparisons: https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...
See the Rust RFC on the subject for motivations and comparisons: https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...
I'm not a language guy so I don't know anything about generalized pattern matching. Maybe it is better. But for my own use, "if let" ensures that I always take care of any possible nulls in my code, while also keeping the conditional code in the same scope as the verified variable. There's no easy way to leave pointers dangling or uninitialized. The language design forces me to organize and think about my code in a much better way.
With generalized pattern matching, your code could (among other things) take the form of
case result of
Just x -> <do something with x>
Nothing -> <do something without x>
I'm not sure if this is the case in your example, but at least in Swift, the "if let" block or chaining for optionals is mandatory. This should mean that it's impossible to have a dangling/null pointer unless you use the force dereference operator. (And that's something that should almost never appear in your code!) You don't get the choice of being lazy or forgetting about checking your pointers: it's a conscious decision either way.
Personally, I appreciate that the language naturally makes me organize my code better and more safely.
Personally, I appreciate that the language naturally makes me organize my code better and more safely.
It is, and you can pattern-match Optional in Swift, something along the lines of
switch optional {
case .Some(let numeral):
println("Caught a \(numeral)")
default:
println("Nothing to catch")
}The nested if-let statements of doom have been one of my major annoyances -- so glad to hear unwrapping multiple optionals in a single line landed in 1.2.
The "wrapping the optionals in a tuple and using switch to pattern match" hack always seemed dirty, and this is a huge step in the right direction for code readability.
The "wrapping the optionals in a tuple and using switch to pattern match" hack always seemed dirty, and this is a huge step in the right direction for code readability.
Coming to Swift as a Scala developer I really enjoy using the language. While it lacks the functional completeness of other functional languages I like writing it, it's specific set of features is very handy and easy to pick up. I think Apple did a great job building a pragmatic language that gives people good constructs and lets them get their jobs done rather quickly. I'm looking forward to Swift on Xcode stabilize and mature.
This is so strange. Right now we have
iOS 8.2 beta and 8.3 beta
XCode 6.2 beta and 6.3 beta
How is the release cycle going to work? When will 8.2 and 8.3 come out and which is more stable for Swift work.
iOS 8.2 beta and 8.3 beta
XCode 6.2 beta and 6.3 beta
How is the release cycle going to work? When will 8.2 and 8.3 come out and which is more stable for Swift work.
Xcode 6.2 basically only exists for the Apple Watch. I think iOS 8.2 is similar, but I'm less familiar there. Xcode 6.2 has no significant Swift changes that I'm aware of, so if you're just looking at Swift, you should either use the latest public 6.1 release, or the 6.3 beta to get the newer stuff. The release timing will presumably be that .2 comes out with the watch whenever that ends up being, and .3 will be a bit later.
Thanks.
This might be easily overlooked: optional has been introduced (back-ported?) to Objective-C in the form of nullability annotation!
No it hasn't.
Optional is a Swift type that contains a value of any type. Obj-C doesn't have anything matching that behavior at all.
What's been done here is Obj-C has gained the ability to annotate any pointer valued type as either nullable or non-nullable. This does not affect the runtime behavior of the code in the slightest. It doesn't even affect the semantics of Obj-C. All it does for Obj-C is let the compiler yell at you if you pass nil to a non-nullable parameter / property.
The real point of these annotations is so Swift can be more intelligent when translating the obj-c API to Swift, choosing to use the correct optional type (or no optional type at all).
Optional is a Swift type that contains a value of any type. Obj-C doesn't have anything matching that behavior at all.
What's been done here is Obj-C has gained the ability to annotate any pointer valued type as either nullable or non-nullable. This does not affect the runtime behavior of the code in the slightest. It doesn't even affect the semantics of Obj-C. All it does for Obj-C is let the compiler yell at you if you pass nil to a non-nullable parameter / property.
The real point of these annotations is so Swift can be more intelligent when translating the obj-c API to Swift, choosing to use the correct optional type (or no optional type at all).
Not exactly. ObjC code cannot usefully benefit from those annotations (yet? more likely ever). At most, it's good for documenting your ObjC code for fellow readers. The actual use appears in the Swiftland where instead of implicitly unwrapped optionals you get proper explicit optionals or explicit non-optionals.
The benefit to working with the Cocoa APIs will be immense, though.
I assume that, now that this feature exists, Apple will begin annotating their Obj-C APIs.
I assume that, now that this feature exists, Apple will begin annotating their Obj-C APIs.
They already started doing it a few months ago with private annotations. This "nonnull"/"nullable" syntax is a result of their work on annotating Cocoa APIs.
They've been doing it for a while in the Swift overlay module. I'm really happy that this is officially added to obj-c because it provides very valuable API documentation, even if it won't have much practical effect on the code.
It looks like the annotations will allow the compiler to produce warnings when compiling the Objective-C code, so that's something:
"However, nullability annotations—in addition to improving the experience in Swift—provide new warnings in Objective-C"
"However, nullability annotations—in addition to improving the experience in Swift—provide new warnings in Objective-C"
This is quite horrible. I wish they would leave Objective C alone.
This is practical. It's something you wish for within a couple hours of Swift.
let x : SomeThing
if condition {
use(x)
let x : SomeThing
if condition {
x = foo()
x = bar()
use(x)
so, in c++ you can do initialization of const value via lambda closures that are immediately evaluated:
const int a = [=](){
//do stuff here that returns an int:
if (condition) { return foo(); } else { return bar(); }
}();
let x: String = {
if 3 == 4 {
return "Hello"
} else {
return "Goodbye"
}
}()
let x = (3 == 4) ? "Hello" : "Goodbye"[deleted]
short of having a language mechanism for doing an 'uninitialized' let, conditional operators could work:
let x : Something = condition ? foo() : bar()
but yeah, it would be nice to defer initialization of an immutable.
let x : Something = condition ? foo() : bar()
but yeah, it would be nice to defer initialization of an immutable.
often times you want to do more stuff in either case so ? does not always work. The if-else approach is more general.
You could also do this:
let x: Something = {
if condition {
someSideEffect()
return foo()
} else {
anotherSideEffect()
return bar()
}
}()
Sad that Swift doesn't use an expressive if, then you could just write:
let x: Something = if condition {
// do stuff
foo()
} else {
// do other stuff
bar()
}That's something I really miss in other languages—the ternary operator is just not good enough for when you have a condition like this. In lisp it's 3 lines which is just the right amount when in other languages you have 6 lines (and until now unnecessary mutability) or only one.
Note that it's no longer "would," this is a feature included in this beta. OP's code is now legal.
Let's hope you don't have a baz.
I wish the es6 const would allow this.
This is the release that makes you go "people were insane to think that Swift 1.1 was anything near usable".
The type inferrence fix ("Type inference for single-expression closures has been improved in several ways:") is the most annoying one for me. Glad they've fixed it. Sure, compiling faster and having less crashes is nice. But that means nothing if it isn't compiling _correctly_.
Really happy to see this, was worried we'd have to wait for WWDC for further improvements. For me personally, it's nice to see Swift support for GLKMatrix and GLKVector now, which was an issue I just ran into just a few weeks ago.
How about opening Swift compiler source code (and porting it to other platforms?)
And, what are the OS requirements for xcode 6.3? Is it possible to install it to old macosx system (snow leopard, for example)?
Judging by previous Apple behaviour they will wait until Swift is more mature before open sourcing it. I suspect it will be 1.5 - 2 years before we see an open source version.
Xcode 6.3 requires OS X 10.10 Yosemite
It says this release (6.3) requires Yosemite (but includes SDKs for 10.9 and 10.10).
For the record, 5.x doesn't even run on Snow Leopard.
"5.x doesn't even run on Snow Leopard."
Which is a shame because OSX 10.6.8 was the most stable, zippiest performance OSX ever and still had the nice virtual desktop. Sadly I lament the old virtual desktop. I'd still be on it if I could be.
Which is a shame because OSX 10.6.8 was the most stable, zippiest performance OSX ever and still had the nice virtual desktop. Sadly I lament the old virtual desktop. I'd still be on it if I could be.
Shouldn’t Apple finish designing the language before they even consider porting it elsewhere?
Stop it with the "open and porting". They are not going to do it.
I'm not so sure. Chris Lattner was giving some hints around Twitter on how big deal they want to make out of Swift (that is, a ubiquitous systems program). This gives me hope that it'll become open as Clang and ported to other platforms.
Just like FaceTime. It won't happen and all the rumors and gossip based on a few comments will just give false hope to people. Swift was designed to lock-in developers just when objc<->java converters were gaining popularity.
FaceTime is different. I heard how everyone at Apple was surprised when Jobs mentioned "open standard". Here, on the other hand, core team is looking forward making Swift a bigger deal than just Apple's pet language.
Sorry, talks about "designed to lock in" is a non-falsifiable theory. If you wanted to build a language for the future and even make it open once it's tested and polished, you would do the same thing: gather a small team to work privately without distractions, make it grow in a controlled environment (so you can safely make breaking changes fixable with some migration tools) and when it's mature enough, release it wide open.
I think there's a practical reason for Apple not to lock-in using a programming language. Proprietary tools limit amount of talent being provided to the platform. Really smart brains would spend time either in suboptimal open platforms or choose some other garden (e.g. .NET, Java). It's one thing to lock in consumers into an ecosystem, it's another to detract smart developers by threatening them with lock in.
Sorry, talks about "designed to lock in" is a non-falsifiable theory. If you wanted to build a language for the future and even make it open once it's tested and polished, you would do the same thing: gather a small team to work privately without distractions, make it grow in a controlled environment (so you can safely make breaking changes fixable with some migration tools) and when it's mature enough, release it wide open.
I think there's a practical reason for Apple not to lock-in using a programming language. Proprietary tools limit amount of talent being provided to the platform. Really smart brains would spend time either in suboptimal open platforms or choose some other garden (e.g. .NET, Java). It's one thing to lock in consumers into an ecosystem, it's another to detract smart developers by threatening them with lock in.
There is always hope I guess.
Swift library is Cocoa and even if they eventually open Swift, it is going to be as useful as Objective-C is outside Mac OS X and iOS.
Personally I don't care. What I care is about tools that make my customers happy.
Swift library is Cocoa and even if they eventually open Swift, it is going to be as useful as Objective-C is outside Mac OS X and iOS.
Personally I don't care. What I care is about tools that make my customers happy.
Swift has its own standard library, Foundation for things that fall outside the purview of the native stdlib (e.g. JSON parsing and regular expressions), and ApplicationKit/UIKit for GUI stuff. A multiplatform Swift + stdlib would already be quite useful for non-GUI applications on other platforms.
There are already lots of ML based languages to choose from with more use in the market than Swift.
A Swift compiler without the Mac library will be a very poor choice in regards to any existing ML language.
A Swift compiler without the Mac library will be a very poor choice in regards to any existing ML language.
Potential users can decide whether or not it's a poor choice themselves. I suspect the language would be more popular than a strict reading of its merits might suggest.
My understanding is that FaceTime was not opened up more due to the VirnetX lawsuit, and the subsequent redesign that meant all video streams were proxied through Apple servers.
So, I think it's more complex than you're admitting.
So, I think it's more complex than you're admitting.
>> "My understanding is that FaceTime was not opened up more due to the VirnetX lawsuit"
First I've heard of this. Glad there was actually reasoning behind not making it open as promising that and then going back on it without telling anyone why was very strange.
First I've heard of this. Glad there was actually reasoning behind not making it open as promising that and then going back on it without telling anyone why was very strange.
"the VirnetX lawsuit"
Garbage patents stabbing the software industry in the back yet again.
Garbage patents stabbing the software industry in the back yet again.
Was introduced to this today: http://www.elementscompiler.com/elements/silver/
I'm really not sure about that. The language is going to gain much more traction if it's open, QED. That's a benefit to Apple, and I think they know that.
The only reason I can see to not open it up at the moment is that they're not ready for it yet. I reckon it'll come soon enough.
The only reason I can see to not open it up at the moment is that they're not ready for it yet. I reckon it'll come soon enough.
[deleted]
[deleted]
Why is being logged-in required to view the Release Notes?
Because Apple chooses to only give access to betas and their release notes to registered developers.
How does that benefit Apple?
They probably aren't interested in catering their beta kit to people who aren't Apple Developers... A good way to cut out a ton of noise in one step.
For Yosemite they did an open beta: https://appleseed.apple.com/sp/betaprogram
But in that case, it makes sense to get bug reports from non-developers.
But in that case, it makes sense to get bug reports from non-developers.
Still, as I remember, the release notes were still only presented to developers.
You'd have to ask Apple. I have no idea. But if I were to venture a guess, I'd say it has something to do with minimizing the press jumping all over speculative statements for features that are weeks (if not months) away from release still. But that's just one thought. I really have no idea.
[deleted]
You only need to be at the free level though, not the $100/year, so it's not much of a barrier.
That doesn't seem to be the case. I just made a free account quick to test this, and it won't let me access the betas without being a member of the paid iOS developer program.
My free account can access the release notes though. Which I admit is not that great.
How are you getting to them? Trying the obvious avenues from a free account only gets me release notes up to 6.1.1.
This link from the blog post works for me from my very old free account: https://developer.apple.com/devcenter/download.action?path=/...
Interesting. That works from my free account as well. However, I see no way to actually obtain that URL through the official site. Did I miss something? Is this a bug on their part?
I just downloaded 6.3 beta using my free account.
Glad enums now work correctly with Objective-c.
That's a nice example of "if you're not embarrassed of 1.0, you shipped too late".