Can Epochs change the definition of a stdlib trait?

[CAD97]

That’s what the blanket implementation impl<I, T> Index2<T> for I where I: Index<T> comes in. a[b] would just (ignoring auto-ref and friends) desugar to ::std::ops::Index2::index(a, b), and Index2::index(_) is equivalent to Ok(Index::index(_)) due to the blanket impl.

[dhardy]

Also, FTR, personally I see .unwrap() as the thing to use when I’m prototyping something; proper error handling can come later, and the spots are easily grepped for.

@jjpe good that you try to good error-handling everywhere. But is there actually something useful you can do to handle array index out of bounds? Because most people clearly don’t think so.

I agree that returning Result<..> is often the right thing to do, but not always.

in my case uncontrolled panicks are simply unacceptable

Unless you avoid all allocation and recursion and are very careful about all code you use and are certain you have sufficient stack-size, this is impossible. That’s a high bar to reach for, just to make your program not panic, and still not sufficient to prove your program is correct. Do you really need that?

[jjpe]

Indeed in general it’s impossible to 100% guarantee that panicks won’t occur. But in practice things like OOM are a nonissue unless you have either incredibly demanding software (exists, but is relatively rare across the entire software landscape, and not really applicable here) or unless you have a memory leak somewhere (much more likely in general), or unless the hardware is constrained (not applicable at all here).

So I agree that OOB indexing is a bug, but here’s my use case: I have written an interpreter that has indexing in the language, which is just passed through to Rust. The current implementation of it uses a custom method to do index-like operations, and works fine. But what I want is more distinctive source code for those operations to make the indexing passthrough operations (which happen now anyway) in Rust sources stand out. The Index trait is 95% of the way there, it’s just this still-somewhat-arbitrary-sounding definition around the return type for the .index() method. If the Index trait did not mandate panicking on OOB (it does this through a lack of alternative options), it would fit this use case. The thing is, the interpreter, when it runs in production, shouldn’t panic because an OOB means a faulty input to the interpreter here, not a faulty implementation. Hence the user should be notified, not have the process panic.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.