It is currently impractical to create checked counterparts of other Csr methods, as this will require significant code duplication. It's easier to make breaking changes in one of the further major releases, moving away from panic to Error and Option in the entire Csr API.

Agreed. Mind adding a new issue, so we can track it in the milestone?

I realize we don't do it anywhere else, but should we derive std::error::Error for CsrError. (And similarly in your other PRs).

I think we shouldn't do this, since CsrError is already described using Display and Debug, for a combination of which the trait std::error::Error is implemented by default.

I don't think it is?

let err: &dyn std::error::Error = &CsrError::IndicesOutBounds(0, 0);

the trait bound `CsrError: StdError` is not satisfied

(btw, the tuple-struct error could use some named fields instead :) )

Agreed. Mind adding a new issue, so we can track it in the milestone?

Good idea, opened #724

I don't think it is?

let err: &dyn std::error::Error = &CsrError::IndicesOutBounds(0, 0);

the trait bound `CsrError: StdError` is not satisfied

Oh, I'll add such blancked implementation:

impl std::error::Error for CsrError {}

(btw, the tuple-struct error could use some named fields instead :) )

In this particular error, both tuple fields are equivalent, and the naming options node_ix_1 and node_ix_2 seem too verbose. I am glad for suggestions if there is a better naming option for the fields.