You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Transition to using fixed size arrays for dimensions #6
I'm working on fixed size array dimension now. In concrete, [usize; 2] is used instead of (usize, usize) and so on.
Simpler and sounder dimension code. Generalize to integer generic parameters (assuming that will happen before variadic generics!)
We can allow more operations on array shapes, in the way that was proposed by @b52
PSA: Switching to the explicit size aliases like Ix1, Ix2, Array1, Array2 will make your code mostly ready for the transition. Generic code (Array<A, D> where D: Dimension) should not need any change.
I have considered making the opposite change a few times. I agree that arr[(1,2)] looks pretty clunks but it has the advantage of being able to do Range indexing properly, i.e. arr[(.., 2)]. Are you planning on just removing this type of indexing or do you have some plan to do it with fixed size arrays?
Ok, the description of the issue in the first post here is a red herring -- the syntax used in indexing is already achieved using conversion traits and that part is "easy". I understand that heterogenous tuples would make interesting things (however do note that Index/IndexMut don't support custom view types, so we don't have much fun there).
The big change here is going to 2d Arrays (for exampmle) as Array<f32, [usize; 2]> or maybe Array<f32, Dim<[usize; 2]>> (of course there are type aliases for the dimensionalities).
Activity
bluss commentedon Dec 27, 2015
Indices of such added in #34, but it's just a step.
bluss commentedon Oct 24, 2016
I'm working on fixed size array dimension now. In concrete,
[usize; 2]is used instead of(usize, usize)and so on.PSA: Switching to the explicit size aliases like
Ix1,Ix2,Array1,Array2will make your code mostly ready for the transition. Generic code (Array<A, D> where D: Dimension) should not need any change.AtheMathmo commentedon Nov 3, 2016
I have considered making the opposite change a few times. I agree that
arr[(1,2)]looks pretty clunks but it has the advantage of being able to do Range indexing properly, i.e.arr[(.., 2)]. Are you planning on just removing this type of indexing or do you have some plan to do it with fixed size arrays?bluss commentedon Nov 3, 2016
Ok, the description of the issue in the first post here is a red herring -- the syntax used in indexing is already achieved using conversion traits and that part is "easy". I understand that heterogenous tuples would make interesting things (however do note that
Index/IndexMutdon't support custom view types, so we don't have much fun there).The big change here is going to 2d Arrays (for exampmle) as
Array<f32, [usize; 2]>or maybeArray<f32, Dim<[usize; 2]>>(of course there are type aliases for the dimensionalities).