The only issue there is that
 itself is already bound to the
Index trait, so the syntax would have to differ somehow to disambiguate the 2.
@sfackler I’m aware of the
get function. What I mean is that I want the
 syntax (or something like it) because it would help clarify intent. But using that would introduce potential for panics in code where there currently is none. My ideal solution is something with semantics similar to
get (it could also return a
Result) but also with syntax that’s to the point. And looking distinctive from regular method calls doesn’t hurt either.
That is also what my comment was referring to: today, if you want the neat
 syntax, you get forced to introduce potential for panicks due to the definition of the
@gbutler I’m not confusing anything. What I’m saying is that I want something with properties of both
 syntax and recoverability, and current-day Rust won’t let you do that. I see no reason why something like
&my_datastructure[idx]? couldn’t work. Or rather something like it, since the
 syntax ship itself has sailed by now. But what would be appropriate is a tougher question, as the 3 pairs of brackets already serve a purpose in Rust. Perhaps something like
&my_datastructure[[idx]]?, or is it too noisy?
What legitimate algorithm involving indexing should perform attempted computations on out-of-bound indexes?
My use case isn’t so much encoding an algorithm as it is making child accesses in a tree like structure stand out. In either case indexing out of bounds is a bug (is there any use case at all where that is not true?), but in my case uncontrolled panicks are simply unacceptable, and here at least in principle it’s preventable. And in fact with the current code (which doesn’t use
 at all) panicks are prevented. It would just be nice to make child indexing stand out in the source code a bit more, which using
 would accomplish.
@dhardy There’s nothing smelly about a method that returns a
Result (or an
Option for that matter). In fact, if the operation can fail, it’s generally the sane thing to do I’d say. The only reason I see to use a panic is if there is nothing that could possibly be done at all to recover, no matter the circumstances e.g. when the host is out of memory. Well, that’s a fairly small set of circumstances. In pretty every other case using
Result as a return type at least allows the caller to decide what to do. If that caller decides to inappropriately call
.unwrap() on it, then the program panicks, yielding similar behavior to a forced panic. On the other hand, at least the caller has the option to do something with the error signal.
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.
It’s never something that is meant to replace proper error handling, rather it’s a stall tactic to allow me to temporarily focus on then-more-important matters e.g. the actual program design.
@withoutboats Unfortunately that wouldn’t be enough, as the
index method returns a borrow.