251–260 of 289 posts
Earlier quoted context omitted.
The standard library is one example. Indexing into a vector unwraps, as do many other stdlib functions.
> Indexing into a vector unwraps That's what it's supposed to do, RTFM. Use .get() for safe access.
Earlier quoted context omitted.
the docs[0] are clear: > be careful: if you try to access an index which isn’t in the Vec, your software will panic! > Use get() and get_mut() if you want to check whether the index is in the Vec. In my experience, most people are using get() if the source of the index is untrusted [0]: https://doc.rust-lang.org/std/vec/struct.Vec.html#indexing
A lot of these Rust complaints are just people not reading the docs (not trying to say Rust doesn't have legitimate usage friction; of course it does). Pro tip: most popular crates have excellent documentation (I know it's a shocker coming from other languages). So, check stuff before you use it. I assume this is because the ecosystem lowers the barrier to entry for writing an generating documentation (compared to ot…
Earlier quoted context omitted.
It's not exactly Java, but: Cons(1, Cons(2, Cons(3, Nil)))
Actually, Java does have sum types nowadays, and you can write a recursive list implementation like “new Cons(2, new Cons(3, Nil.nil()))”. Here is a definition for a Maybe type, converting it to a List is left as an exercise to the reader :) : https://news.ycombinator.com/item?id=35133670
Rust will only be a real competitor once it’s generics can hold a candle to C++ templates.
The article specifically mentions not holding said candle as a positive. I would too. They're confusing at best and undebuggable at worst, and virtually everything you can do with them that you can't do with generics is something it'd be better for everyone if you didn't do.
Earlier quoted context omitted.
Also the ISO is also very averse of patents. They will probably not standardize anything patent-encumbered. They would probably require invalidating the patent first before accepting it in the standard. Having said that this is the first time I ever heard of methods on enums being patented, what a ridiculous patent. It's a good thing then that C++ doesn't have methods, it has "member functions" :). Also C++ allows us…
WG21 (the "C++ Committee") is under JTC1 the Joint Technical Committee ("joint" between ISO and IEC), now, you might know of a few other famous products of the Joint Technical Committee's sub and sub-sub committees, including JPEG (that's the Joint Photographic Experts Group getting a shout out in the name of the standard) and MPEG. Those standards both required patented "inventions" to implement in full. The patents…
Earlier quoted context omitted.
Yes, but: - nobody uses it in the ecosystem. As outlined in the article, a lot of value of Option/Result is derived from their pervasiveness in the Rust ecosystem. C++ is far from this - the ergonomics of it are terrible: no pattern matching, structural variants instead of named variants (yes you can emulate that with wrapper types but meh), lambda-oriented matching means you cannot as easily do things like early ret…
Variant types where one has to use objects as types don’t come up that often in API design or data structures in my experience with mobile and system programming on e.g. Linux. I think I’ve genuinely had to use them only a few times. Error types are probably the most popular incarnation of that. There’s several libraries available and they will be part of the C++ standard. This is a case of the Rust community oversel…
Sum types reify control flow into an object from which said control flow can be retrieved. Compiler checked sum types remove the possibility of retrieving inconsistent control flow.
The transform is equivalent to callback to future.
It's one of the things that looks unimportant until you use it. After that, the absence is repeatedly experienced when working with C++. We don't use tagged unions much because the ergonomics are terrible.
Earlier quoted context omitted.
Exceptions are an optional feature. Also, if sufficient amount of constructors are marked noexcept, then the variant can never be valueless. Implementations are optimized accordingly. You also don't have to handle the exception, in which case you won't access the variant again anyway. Or it gets handled where the variant is teared down. It's very unlikely that it gets handled where the variant is constructed or assig…
They aren't as per ISO C++, even though all compilers allow to disable them in non standard conforming ways.
Granted, it's more awkward when you consume 3rd party libraries, but you can still wrap them in noexcept interfaces and be fine with terminating when an exception is actually thrown or do something else. Not much different to a panic.
Earlier quoted context omitted.
when I started moving from C++ to Rust I found the easiest initial way to make sense of the borrow checker was to basically imagine that almost every argument passed in a function call was wrapped in a std::move.
every argument is passed by move, not just almost every. Types that implement Copy are still moved. Copy just means “the original value is still usable after move”.
Makes me wonder out loud if the C++ community isn't going to add some kind of std::borrow/std::return_borrowed to the language. If that's even feasible with the type system and reference system as it is today.
Earlier quoted context omitted.
i haven't done c++ in a million years, but huh, you can! can't have any types w/ non-trival copy constructors in a union, though, apparently, which is quite the restriction. https://gist.github.com/erinok/c823af95db408653c7e42ab189307...
> can't have any types w/ non-trival copy constructors in a union, though, apparently, which is quite the restriction. That was removed in C++11. The rule now is: > Absent default member initializers ([class.mem]), if any non-static data member of a union has a non-trivial default constructor ([class.default.ctor]), copy constructor, move constructor ([class.copy.ctor]), copy assignment operator, move assignment oper…