Type-Safe Unions in C++ and Rust
51–60 of 140 posts
Re: Type-Safe Unions in C++ and Rust
#52Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?
Re: Type-Safe Unions in C++ and Rust
#53Earlier quoted context omitted.
One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…
Ada and Pascal are not really research languages, though. But still, there are improvements taken from research, see Ada 2012 contracts for example.
Re: Type-Safe Unions in C++ and Rust
#54Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?
Re: Type-Safe Unions in C++ and Rust
#55> but it’s the first language I’ve experimented with that has made them a first-class feature It is a feature of ALGOL68, Pascal, Ada and quite some newer languages: https://en.wikipedia.org/wiki/Tagged_union
One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…
Smalltalk has had that since the early 1980s
Re: Type-Safe Unions in C++ and Rust
#56Earlier quoted context omitted.
One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…
the concurrency safety model (Send+Sync), though that might be old too Smalltalk has had that since the early 1980s
Re: Type-Safe Unions in C++ and Rust
#57Earlier quoted context omitted.
well, yes. The nice thing is that in C++ can be implemented purely as a library. Sometimes C++ feels like the high level languages assembler.
Unfortunately that means they lack lots of the pattern matching niceties that you get in languages with builtin ADTs. There is an impressive paper about implementing pattern matching on sub-classes, but it's pretty hackily done using the preprocessor, and could definitely do with some language support: http://www.stroustrup.com/OpenPatternMatching.pdf
Re: Type-Safe Unions in C++ and Rust
#58Hopefully there can be a new function returning optional at some point in the future.
Re: Type-Safe Unions in C++ and Rust
#59Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?
Lot of syntactic sugar recently added to C++ and a lot more in C++17. The structured bindings in particular are really excellent ways for unpacking tuples and structs with type inference into new variables automatically.
Re: Type-Safe Unions in C++ and Rust
#60Earlier quoted context omitted.
Erm... I think Dennis Ritchie would have had a few things to say about that.
good point; though, while designed to work well with each other, neither unix nor C require the other.