Swift 1.2 and Xcode 6.3 beta
developer.apple.com
developer.apple.com
That's a nice example of "if you're not embarrassed of 1.0, you shipped too late".
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.
https://twitter.com/practicalswift/status/564921024782041088
https://github.com/practicalswift/swift-compiler-crashes/com...
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.
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.
enum Foo {
Bar,
Baz(i32),
Qux(f64)
}
if let Bar = item {
// do something
} else if let Baz(val) = other {
// do something with val
}
https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...
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.
(if-let [name name-whose-value-is-possibly-null]
(something-to-do name))
if (mytype* p = find_or_null(blah))
foo(*p);
if (auto opt = find_or_none(blah))
foo(*opt); case result of
Just x -> <do something with x>
Nothing -> <do something without x>
Personally, I appreciate that the language naturally makes me organize my code better and more safely.
switch optional {
case .Some(let numeral):
println("Caught a \(numeral)")
default:
println("Nothing to catch")
}See the Rust RFC on the subject for motivations and comparisons: https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...
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
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.
I assume that, now that this feature exists, Apple will begin annotating their Obj-C APIs.
"However, nullability annotations—in addition to improving the experience in Swift—provide new warnings in Objective-C"
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).
let x : SomeThing
if condition {
x = foo()
x = bar()
use(x)
let x : Something = condition ? foo() : bar()
but yeah, it would be nice to defer initialization of an immutable.
let x : Something = outer_conditional ? baz() : conditional ? foo() : bar()
let x = conditional1 ? bar() :
conditional2 ? baz() :
conditional3 ? quux() :
someDefault let x: Something = {
if condition {
someSideEffect()
return foo()
} else {
anotherSideEffect()
return bar()
}
}()
let x: Something = if condition {
// do stuff
foo()
} else {
// do other stuff
bar()
} 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"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.
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.
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.
A Swift compiler without the Mac library will be a very poor choice in regards to any existing ML language.
So, I think it's more complex than you're admitting.
Garbage patents stabbing the software industry in the back yet again.
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 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.
But in that case, it makes sense to get bug reports from non-developers.