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.
The news here is really an update that they're still thinking about it and it won't be in Swift 4.
Chris and his crew are amazing and the vibrant community definitely helps/challenge them and will bring us things like:
- concurrency (at least planned)
- cyclone/rust memory model!
- syntactic sugras
Got any links with more information?
- Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance (for example, in real time audio processing code). More pertinent to the goals of Swift 4, this feature is important because it fundamentally shapes the ABI. It informs code generation for “inout", how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling.
Can definitely see the use case for swift expand a bit with this in its wings.
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.
I think rust approach of having strong guarantees over memory ownage, and thus being able to share memory in a safe way, is a better direction for swift.
It is not coincidence that message passing is the core concept in the original OO paradigm and in design of fault-tolerant distributed systems. Cells do message passing too.
I am not sure what is being copied here. Messages are just structured data (a molecule) in otherwise share-nothing architecture.
This is not about "fault-tolerant distributed systems" though, but for "performance-first" for very CPU and memory expensive programs (video and audio processing, number crunching, etc).
He advocates those for totally different use cases.
So copy on write ends up being copy.
Well, theoretically you can add new syntax without altering/affecting existing syntax and programs, and similarly for ABI.
> 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.
Third party vendors will have to adhere to the same requirements to be ABI compatible, because not all changes will be compatible.
Does anyone who uses Swift on Linux have any comments, suggestions, use cases, etc.?
I haven't dug into testing Foundation support yet. From what understand, it's mostly implemented and they're working on finishing it. Also right now they only support 64bit OSes and only have prebuilt binaries for Ubuntu 15.10 and 14.04.
It's designed first and foremost for developers deploying on UNIX/Linux.
You don't even need much css:
Of course bettermotherfuckingwebsite.com uses #444 on white. bestestmotherfuckingwebsite.com probably dials it up to #777 with a light sans-serif.
Sure I have, and every time I'm annoyed by the archive site layout.
> You must've taken a wrong turn getting here.
No need to get personal, take a step back cool down and don't take things so serious.
> Of course bettermotherfuckingwebsite.com uses #444 on white.
Yeah it's also a bit too bright for my taste, but the general point still holds.
So your criticism seemed out of touch and (can't believe I'm quoting pg) "middlebrow."
(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.)