Hacker News Reader

Comment by sapiogram | Hacker News Reader

> Rust is a subset of C++ with extra static checks.

While this may work as a rough heuristic, it's not true in theory nor in practice. First example that comes to mind: Rust has proper sum types (Called enums), which are used everywhere, and C++ doesn't have anything like it.

View on HN

https://en.cppreference.com/w/cpp/utility/variant

As far as I've seen, std::variant's ergonomics isn't remotely competitive with rust sum types. C++ lacks the syntax.

Yet they're both conceptually the same old thing: tagged unions.

In C++ everything is just more awkward since everything is bolted on as an afterthought in the stdlib but then lacking language syntax sugar to make its usage convenient.

E.g. the (somewhat weird looking) equivalent to Rust's match is called 'visit' in C++:

https://en.cppreference.com/w/cpp/utility/variant/visit2

I can create tagged unions in literally any language not just C++ including Assembly. Rust having syntactic and compiler checked support for them as a foundational part of the language is a material difference in the design that differs fundamentally from C++. So the the point still stands.

Syntax is on its way...

Source?

There are at least three proposals in flight for C++26, if they reach an common agreement on time, or it has to be done by C++29, remains to be seen.

Just search for the various revisions,

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/

I'm not even using Rust but I think you should stop hyping things that won't exist for years as if they were real and proven, like you've been doing a lot.

I've had a quick look at one of the proposals behind the link and it's no comparison with the existing Rust way. Even std::variant itself is a crutch (being templatized by a list of types), not comparible with true algebraic datatypes.

`std::variant` is a clever piece of template hackery, but it doesn't come close to Rust enums. `std::variant` has no named variants, no pattern matching, no exhaustiveness checking. In Rust, it's not unusual to have an enum with dozens of variants, good luck doing that with std::variant.

I'm sure you could technically emulate all this in C++ is you keep throwing template metaprogramming at it, but at that point anything is a C++ subset and the statement loses all pratical meaning.

Pattern matching is on its way, one of the possible approaches being discussed,

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p26...

Coming right after profiles are done, probably?

One has nothing to with the other.

That is the thing with committee driven languages, with multiple vendor implementations.

Not everyone is on the same room voting for the same features, and not everyone is implementing the features in any specific order.

By the way, I would rather have Safe C++ than profiles, but do not vote, so whatever.

I'm not saying they are related, just saying that the committee committeing is going to take half a decade at least for both.

Well, it is still going to be faster than WG14 ever doing anything useful improve the C's security model regarding arrays and strings.

It has hardly moved since 1989, and annex K doesn't count, given its broken design.

Anyway I am still mostly stuck with .NET Framework, Java 17, node 20 in many commercial deployments, so it isn't like everyone cares that much to update to latest, given existing business decisions.

Those kind of industries don't care about programming language featurities anyway.

I understood your joke, but we just found out a few hours ago what happened in Hamburg, and while neither of these features made it yet, they're seemingly going in opposite directions:

pattern matching had a poll in forwarding to the CWG, and it was mostly in favor, though enough were against it to not reach consensus

profiles had a poll in forwarding to the CWG, and it was split down the line in terms of for/against.

Given the previous votes on profiles being nearly unanimously for, I'm interested to see what people have to say about what went on.

I don't even think Bjarne could claim with a straight face that hacking variants into the standard library was a good idea :)

He only gets one vote among 300 something committee members, so his opinion while important, is largely irrelevant.

By the way, ever noticed that after C89, neither Ritchie nor Dennis ever had anything else to do with how WG14, or the compiler industry vendors, decided to take C onwards?

The original Plan 9 C compiler isn't even standards compliant.

And this has what to to with variants?

Bjarne's opinion on variants hardly matters to WG21 working process.

What are you even talking about?

Also the move semantics of rust completely change how you reason about variables.

recently learned that move semantics in C++ leave the moved-out object in this weird state... and this after almost 25+ years of using C/C++ - lol....

Reply on news.ycombinator.com