[heavenlyblue]

What do you do when your algorithm works with array indexing and you are never supposed to handle than None within the Option?

Ie if you have indexed array out of bounds that’s a developer’s mistake and not a “condition to be handled up the stack”.

It’s ok to panic if you agree that it’s better to panic rather than end up in a state that will probably cause even more issues down the line

[masklinn]

> What do you do when your algorithm works with array indexing and you are never supposed to handle than None within the Option?

That's where the first clause comes into play:

> Array indexing must be properly tested

Although

> Ie if you have indexed array out of bounds that’s a developer’s mistake

Which developer would be my question.

If it's the person who reified the "algorithm [which] works with array indexing" then fair's fair, it's a bug in the implementation and should not happen, which is why the guideline specifically says:

> should never use functions or instructions that can fail and cause the code to panic

which, assuming the word is used in the RFC 2119 sense means there can be case where calling panic-ing functions is the right thing to do.

If it's the developer who calls the function implementing the algorithm, then either algorithm is failable (and thus so's the function) or the algorithm should take in more specific data structures which statically exclude failing cases. For instance `max` on an empty collection will fail, so either `max` should be failable (which e.g. `Iterator::max` is) or it should only be callable on some sort of `NonEmpty*`.