It looks pretty nice, I hope they didn't forget about concurrency and parallelism. I don't see anything talking about this in the iBook.
I'm sure that the main mechanism will be the existing dispatch queue libraries Apple's other languages use.
The Swift Programming Language
591–600 of 970 posts
Re: The Swift Programming Language
#592[deleted]
Re: The Swift Programming Language
#593Someone bought swiftcasts.com today ... http://whois.domaintools.com/swiftcasts.com
Re: The Swift Programming Language
#594I'm a learning addict. Has somebody tasted it and is this worth it?
Re: The Swift Programming Language
#595Our mentors & curriculum developers went bananas when they heard about Swift – so we announced the first course teaching Swift: https://www.thinkful.com/a/dlp/learn-blue/base/IOS-002
Re: The Swift Programming Language
#596I found the notion of "Optionals" surprising and a bit hard to handle at first. In Objective C it was really easy to lazily allow values to be nil and still do things on them, so it's a bit of a departure. Thinking about it a bit longer, is it because of the clear distinction between non nullable values ans optionals that the compiler can optimise the code so much more ? (I am thinking about the xx times faster than…
I think this is much less to do with performance and more to do with safety. If anything can be nil, NPEs are a fact of life. If you're forced to annotate for the compiler which values can be nil, and then forced to handle the nil case when you consume them, the problem disappears.
I don't think the problem disappears so easily. It puts a signifiant burden on the programmer (on the top of my head, if I have a set of 20 properties in an object, all optionals, I'll have to unwrap them all, even if I can guarantee by knowledge of the data that they're not nil), it will still throw an error if a value became nil after the test, and there is still the implicit unwrapping system that would cause runtime exceptions on nil values.
I see the value of the safeguard, but it seems cumbersome as a language level rule; I hated The boilerplating in Java, and it goes a bit in the same direction. I'm not sure I like the bureaucracy of explicitely testing every single variable that could be nillable to use them, but I'd love to be proven wrong.
Re: The Swift Programming Language
#597"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.
Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know tot…
How about if you're developing in a field where the overhead of higher-level languages would prohibit the device from being made at all?
Do you just put on your idealist hat and say, "Sorry! I can't develop a medical device for you. You'll just have to die. At least no one was required to be careful about their programming."
Re: The Swift Programming Language
#598As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…
I really don't see the Golang influence at all. The multiple- return- value semantic is closer to Ruby's than to Golang's; you're returning a tuple, which happens to have natural syntax in the language. Defining Golang features that don't exist in Swift: - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) - Error types - Relatedly, the "damnable use requirement" and its interaction wit…
It does share Go's `func` keyword, parens-free conditionals, optional semi-colons
Re: The Swift Programming Language
#599Can't find the link to download Xcode beta!
You have to be a developer but... [xcode6 link] https://developer.apple.com/devcenter/mac/index.action Edit: You then have to click "OS X Yosemite Developer Preview". Then scroll down, it's at the bottom of the page
Ah, you have to pay to play!
Re: The Swift Programming Language
#600Has some features from Lisp.