-
Notifications
You must be signed in to change notification settings - Fork 47
More ergonomic slicing #252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I'm leaving this as-is for now, as I'd like to take some time to reflect on this new API. @mulimoen, if you want, I'd very much appreciate your feedback on these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vbarrielle I think this API is very nice to have, and makes sense to include. I don't think I would change anything apart from the nitpicks noted here.
You should do a rebase on current master, the clippy changes I've made will probably give merge conflicts
This was me seeing a single missed type disguise, fixed in #258
As discussed with @mulimoen in #252 (comment) there needs to be a consistent handling of reborrowing throughout the crate. The chosen pattern is the one implemented here: implement on the base method, calling the actual implementation that's defined on the view type, with the appropriate lifetime.
This trait will allow more ergonomic slicing APIs
To be able to extend the lifetime of the `middle_slice` method targeting `CsMatViewI` without having to use an other name, I'm experimenting a new approach, where I re-implement the method for each main variant. Of course I'd still like to be able to write a single implementation, but I guess only a future version of rust, with specialization, or maybe associated type constructors, will be able to help.
There is no need to return an option as the value 0 is the correct one when no bound is present.
As discussed with @mulimoen in #252 (comment) there needs to be a consistent handling of reborrowing throughout the crate. The chosen pattern is the one implemented here: implement on the base method, calling the actual implementation that's defined on the view type, with the appropriate lifetime.
@mulimoen the latest changes should address all your remarks. I've also added the policy on reborrowing on the guidelines to have a point of reference |
Excellent work @vbarrielle! |
As mentionned in #250, the slicing of middle matrices along the outer dimension is quite cumbersome to use, which is particularly visible in the matrix product implementation in
smmp.rs
. This PR tries to propose a more ergonomic API.