Add into_scalar for ArrayView0 and ArrayViewMut0#700
Add into_scalar for ArrayView0 and ArrayViewMut0#700LukeMathWalker merged 7 commits intorust-ndarray:masterfrom
Conversation
| /// let scalar: &Foo = view.into_scalar(); | ||
| /// assert_eq!(scalar, &Foo); | ||
| /// ``` | ||
| pub fn into_scalar(self) -> &'a A { |
There was a problem hiding this comment.
the ArrayView doesn't need to be consumed to allow this (infuriating difference between shared and mut for IndexLonger). I guess one could just as well make this a &self method, it makes a difference for non-copy ArrayViews?
There was a problem hiding this comment.
I thought about it, but then I opted to keep the signature consistent with the other two (Array/ArrayViewMut). Given that it's named into_*, it sounded preferable to consume the input.
On the other hand, taking &self makes it more convenient for ArrayView because you can keep using self afterwards.
I don't know, I would lean on the side of symmetry in this case.
|
Looks good. Continual splitting is good I think. Impl_views isn't even large in ndarray 😄 |
|
Tip, use the https://help.github.com/en/articles/closing-issues-using-keywords names. With "Fixes #688." it closes the issue automatically. I prefer to put these in the PR text (not in the commit log because rebasing and re-pushing causes spam on the issue). |
|
Nifty trick, thanks! |
This addresses #688.
I have taken the chance to re-organize
impl_views, converting it into a folder sub-module to then split it into smaller files with a functionality-related name.I think this makes it easier to navigate the crate (and we should probably do the same for other very big files we have in the repository) but I am ok to revert the changes if you believe otherwise.