12 ms·

If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)`

If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.

mathw 2y ago
I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option<T>.
- sshine 2y ago
  While that is true, there are clippy::indexing_slicing, clippy::string_slice for that: https://github.com/rust-lang/rust-clippy/issues/8184#issuecomment-1003651774 error: indexing may panic --> src/main.rs:100:57 | 100 | rtmp::header::BasicHeader::ID0 => u32::from(buffer[1]) + 64, | ^^^^^^^^^ | = help: consider using `.get(n)` or `.get_mut(n)` instead = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#indexing_slicing
- quotemstr 2y ago
  One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.
  - andrewshadura 2y ago
    I think someone's already created this.
  - jll29 2y ago
    One of my dreams is for someone to create a Rust stdlib, full stop. I love Rust the language, but the current bazar of little bits of functionality scattered around in the form of a zoo of crates is such a mess compared to, say, Java's class library (I/O, data structures, std. algorthms for searching, sorting etc., arranged in a logically and hierarchially named way). I'm not against alternative implementations, but I'd rather have one "official" implementation that everyone knows that covers most cases and makes for the idiomatic reading of source code.
    - OtomotO 2y ago
      No! I mean, yes, but not an official one. The stdlib is where good ideas go to die. Waiting for "pub struct RDBMSInferfaceV17ThisTimeWeGotItRightForSure"
      - thesuperbigfrog 2y ago
        Firm disagree. Sylvain Kerkour described the problems Rust faces by having a limited standard library: "The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware. What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl? Which HTTP framework? actix-web, axum, dropshot or hyper? What about a time library? time, chrono or jiff (how I'm even supposed to find this one)? You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting. I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them" Source: https://kerkour.com/rust-stdx https://kerkour.com/rust-stdx My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous. Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the dependencies are. How well will they be maintained in five years from now? Will I need to find newer libraries and rewrite portions of my project to provide the same features that I have now? I don't know.
OtomotO 2y ago
in the stdlib, yes. In 3rd party crates? Depends!

mathw 2y ago

I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option<T>.

sshine 2y ago
While that is true, there are clippy::indexing_slicing, clippy::string_slice for that: https://github.com/rust-lang/rust-clippy/issues/8184#issuecomment-1003651774 error: indexing may panic --> src/main.rs:100:57 | 100 | rtmp::header::BasicHeader::ID0 => u32::from(buffer[1]) + 64, | ^^^^^^^^^ | = help: consider using `.get(n)` or `.get_mut(n)` instead = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#indexing_slicing
quotemstr 2y ago
One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.
- andrewshadura 2y ago
  I think someone's already created this.
- jll29 2y ago
  One of my dreams is for someone to create a Rust stdlib, full stop. I love Rust the language, but the current bazar of little bits of functionality scattered around in the form of a zoo of crates is such a mess compared to, say, Java's class library (I/O, data structures, std. algorthms for searching, sorting etc., arranged in a logically and hierarchially named way). I'm not against alternative implementations, but I'd rather have one "official" implementation that everyone knows that covers most cases and makes for the idiomatic reading of source code.
  - OtomotO 2y ago
    No! I mean, yes, but not an official one. The stdlib is where good ideas go to die. Waiting for "pub struct RDBMSInferfaceV17ThisTimeWeGotItRightForSure"
    - thesuperbigfrog 2y ago
      Firm disagree. Sylvain Kerkour described the problems Rust faces by having a limited standard library: "The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware. What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl? Which HTTP framework? actix-web, axum, dropshot or hyper? What about a time library? time, chrono or jiff (how I'm even supposed to find this one)? You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting. I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them" Source: https://kerkour.com/rust-stdx https://kerkour.com/rust-stdx My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous. Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the dependencies are. How well will they be maintained in five years from now? Will I need to find newer libraries and rewrite portions of my project to provide the same features that I have now? I don't know.

OtomotO 2y ago

in the stdlib, yes. In 3rd party crates? Depends!