Live data from Hacker News

Swift 1.2 and Xcode 6.3 beta

developer.apple.com

71–80 of 94 posts

Re: Swift 1.2 and Xcode 6.3 beta

#72
post #26

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 po…

> 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

    join :: m (m a) -> m a
"Maybe" (Haskell's standard library Optional) is a monad, so you can unwrap/collapse them using Join.

You can also daisy-chain them together using >>=, a la

    fail1 :: Maybe a
    fail2 :: a -> Maybe b
    result = fail1 >>= fail2
If either fail1 or fail2 fails, the entire "result" function fails (i.e. returns "Nothing").

Re: Swift 1.2 and Xcode 6.3 beta

#73
post #26

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 po…

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.

Why is "if let" preferable to generalized pattern matching?

Re: Swift 1.2 and Xcode 6.3 beta

#74
post #22

Earlier quoted context omitted.

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.

Well, I hear Apple II was stable too. 10.6 is how many years old by now?

Re: Swift 1.2 and Xcode 6.3 beta

#75
post #74

Earlier quoted context omitted.

"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.

Well, I hear Apple II was stable too. 10.6 is how many years old by now?

10.6 did things Apple II wasn't capable of.

Re: Swift 1.2 and Xcode 6.3 beta

#76
post #73

Earlier quoted context omitted.

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.

Why is "if let" preferable to generalized pattern matching?

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.

Re: Swift 1.2 and Xcode 6.3 beta

#77

Earlier quoted context omitted.

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.

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)) [0] https://clojuredocs.org/clojure.core/if-let

C++98 (maybe earlier) has a similar feature:

    if (mytype* p = find_or_null(blah))
        foo(*p);
Still have to dereference p, but at least it's only in scope when doing so is safe. Also goes well with auto and std::optional:

    if (auto opt = find_or_none(blah))
        foo(*opt);

Re: Swift 1.2 and Xcode 6.3 beta

#78

Earlier quoted context omitted.

Because Apple chooses to only give access to betas and their release notes to registered developers.

How does that benefit Apple?

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.

Re: Swift 1.2 and Xcode 6.3 beta

#79
post #73

Earlier quoted context omitted.

Why is "if let" preferable to generalized pattern matching?

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 m…

With generalized pattern matching, your code could (among other things) take the form of

    case result of
        Just x -> 
        Nothing -> 
This works with optionals as well as any other algebraic data type.

Re: Swift 1.2 and Xcode 6.3 beta

#80

Earlier quoted context omitted.

You could also do this: let x: Something = { if condition { someSideEffect() return foo() } else { anotherSideEffect() return bar() } }() But it's kind of ugly.

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.
Post reply on HN