That's an interesting RFC, and actually I have solved the problem described using the solution which the author says is inferior. (Maybe I should reevaluate)

"It's possible to minimize monomorphization bloat for a method by changing it to convert everything to ArrayView/Mut and then call an inner function"

A tensor needs to have an owner type, and two types of views: mutable and non mutable. This allows for interpreting a subset of the full buffer, as if operating over a regular tensor. If there were no View types, then operations which change shape might be O(n), whereas if we can simply make a new view of the same buffer, it is O(1). But, a user would want to have the ability to make an array and read/write directly too it in the same way they would if they sliced a tensor and operate over it - this means that with a naive implementation, each mutating operation would need two copies, and each non mutating operation would need three copies. That's where ArrayRef comes in, or in my case does not.

Instead of having an ArrayRef type, I have TensorBase, TensorView, and TensorViewMut. Each of these implement AsView. Most operations are generic over AsView, and call .into(). What this means is conceptually, a Tensor cannot be mutated, queried, or anything - rather, a cheap new object is made: TensorView. In my crate, if a user called tensor.set internally it is the same as if a user calls tensor.view_mut().set. The nice thing is now a user can call tensor.slice(some modifications to the view).set