Skip to content

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

Merged
merged 11 commits into from
Dec 20, 2020
Merged

More ergonomic slicing #252

merged 11 commits into from
Dec 20, 2020

Conversation

vbarrielle
Copy link
Collaborator

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.

@vbarrielle
Copy link
Collaborator Author

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.

@vbarrielle vbarrielle marked this pull request as draft December 9, 2020 22:02
Copy link
Collaborator

@mulimoen mulimoen left a 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

vbarrielle added a commit that referenced this pull request Dec 18, 2020
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.
@vbarrielle
Copy link
Collaborator Author

@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

@vbarrielle vbarrielle marked this pull request as ready for review December 19, 2020 12:23
@mulimoen mulimoen self-requested a review December 19, 2020 15:05
@mulimoen
Copy link
Collaborator

Excellent work @vbarrielle!

@vbarrielle vbarrielle merged commit be902d6 into master Dec 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants