All of those languages have a runtime that enables this sort of thing. That's not the case in Rust. It's a bit of an unfair thing to knock it for, given the restrictions.
You can do it non-properly in Rust as well, e.g. using unwraps, etc. but even then it's still way better than an UB-ridden component of a C++ codebase.
Absolutely, I was trying to communicate that this is true across a ton of languages. This one isn't super specific to Rust; others may be depending on the exact feature.
No, it's pretty much the same in C[0]. Sorry, my point was not laid out. It was not to be obnoxious, but that one can implement various pattern fairly succintly in C or C++ and thus "is difficult to do in language x" is not a very compelling argument there.
Rust has algebraic datatypes, memory safety, pattern matching, etc, - those are actual things that are, if not hard, then at least tiringly verbose to do in C and C++;
0: enumerating_parser now becomes struct enumerating_parser{}, the constructor becomes a factory function while next() takes in the parser as a state parameter.
It's all good; it's one of the things that's specific to our implementation. Other forms may or may not do this, but I'm pretty sure that it's novel to at least Rust, and maybe C++; there's some discussion that I think it can do this in some circumstances as well.
Rust's behavior makes so much more sense! IMO, implicit conversions is one of C++ biggest weaknesses. Yes, it may save some keystrokes, but it can easily lead to subtle (or not so subtle) bugs.
But the way the Rust compiler works today is quite acceptable already. This isn't a Rust-the-language problem other than in secondary ways that are hard to address by definition (such as "movable" data being the default and Pin<> references being special), it's a Rust-the-library-ecosystem (including, but not limited to, std and/or core) issue. It can only be addressed as such.
The point is that while it's easy to do in C++, it's extremely error prone.
Rust encourages you to write code that works with things like slices and references instead of copying, because the compiler won't let you use them in a way that is error prone.
Fair enough. My argument here is more general than Rust itself, it's relevant to all languages with an Option type and no null. The verbosity can of course vary by language.
reply