Looking back on Swift 3 and ahead to Swift 4
lists.swift.org
Looking back on Swift 3 and ahead to Swift 4
1–10 of 66 posts
Re: Looking back on Swift 3 and ahead to Swift 4
#2Kind of an incomplete article as there is no mention of the environmental cost. Desalination is not a magic solution. Everything is a trade off. Desalination means pumping salt back into the ocean which just compounds the problem.
Re: Looking back on Swift 3 and ahead to Swift 4
#3 > For Swift 4, the primary goals are to deliver on the
> promise of source stability from 3.0 on, and to provide
> ABI stability for the standard library.
Re: Looking back on Swift 3 and ahead to Swift 4
#4Kind of an incomplete article as there is no mention of the environmental cost. Desalination is not a magic solution. Everything is a trade off. Desalination means pumping salt back into the ocean which just compounds the problem.
oops I think you commented the wrong thread
Re: Looking back on Swift 3 and ahead to Swift 4
#5Wow quite intriguing and exciting that swift 4 may have a rust inspired memory model!
Can definitely see the use case for swift expand a bit with this in its wings.
Re: Looking back on Swift 3 and ahead to Swift 4
#6> - First class concurrency: Actors, async/await, atomicity, memory model, and related topics. This area is highly desired by everyone, as it will open the door for all sorts of new things on the client, server and more. We plan to start formal discussions about this in Phase 2, but it is unfortunately crystal clear that a new concurrency model won’t be done in time for the Swift 4 release. This is simply because it will take more than a 12 months to design and build, and we want to make sure to take time to do it right. It also makes sense for the memory ownership model to be better understood before taking this on.
It's great to hear planning and discussion on this is beginning, and that they're being honest upfront about the timeline to see it implemented.
Re: Looking back on Swift 3 and ahead to Swift 4
#7Perhaps, one should borrow message-passing as a standard language idiom, actors and pattern matching on receive from Erlang, the way Akka did, instead of copying hat async/await ugly hacks.
Message passing as a core concept of a language is fundamental and necessary (given that interlop with ObjC is important), and having that and macros gives related control structures for free.
Re: Looking back on Swift 3 and ahead to Swift 4
#8> For Swift 4, the primary goals are to deliver on the > promise of source stability from 3.0 on, and to provide > ABI stability for the standard library. Hm, does this imply that only the stdlib will have the benefit of a stable ABI? IOW, that it won't be possible to distribute compiled artifacts built with different versions of the compiler and expect them to link properly?
I don't think so, it means that the stdlib team will adhere to the requirements for ABI compatibility and the compiler will support this.
Third party vendors will have to adhere to the same requirements to be ABI compatible, because not all changes will be compatible.
Re: Looking back on Swift 3 and ahead to Swift 4
#9Wouldn't First class concurrency in a way breaks ABI and Stdlib as well? ( Otherwise it would be second class )
Re: Looking back on Swift 3 and ahead to Swift 4
#10Kind of an incomplete article as there is no mention of the environmental cost. Desalination is not a magic solution. Everything is a trade off. Desalination means pumping salt back into the ocean which just compounds the problem.
You're in the wrong place, but your argument doesn't make much sense either. The water also quickly ends up back in the ocean. Salt levels don't change.
(You could argue about a miniscule temporary rise in salt levels, but that's more than counteracted by drained reservoirs and melted glaciers, which means the plants are actually minusculely helping the environment be closer to where it was historically.)