proposal: Go 2: ability to slice in a particular dimension for multidimensional slices.

[JCCPort]

For example, if you have the 2 dimensional slice

foo := [][]int {{1, 2, 3},
                {4, 5, 6},
                {7, 8, 9}}

you could select the second column with foo[][1] to give []int{2, 5, 8}.

[seankhliao]

see also #6282

this is difficult because slices represent a contiguous region of memory, to maintain that would introduce new allocations

[ianlancetaylor]

Thanks for the proposal. Please look through the discussion at #6282. If you have something new to suggest, by all means do so. As is I'm inclined to close this as a dup. Thanks.

[ianlancetaylor]

Slices in Go are often referred to as reference types, because if you pass a slice to a function, and the function changes an element of the slice, then the caller sees the change. Similarly, if you take a slice of a slice, and then change an element of the subslice, the change is seen in the original slice.

As far as I can see, in any straightforward implementation of your suggestion of foo[][1], that property would not hold. foo[][1] would return a new slice that does not refer to the original slice.

That seems potentially confusing.

[JCCPort]

Thanks for the response, @ianlancetaylor. From my experience in scientific computing the two main cases that have involved the feature I'm describing (in Python, numpy) would be to define a new variable that is copying the value of the multi-slice (not making a reference), or doing repeated operations to different parts of a multi-slice. I'd like to mention that this is a feature that I've used very heavily in SciComp/particle physics stuff, the implicit vectorised operations that could be done such as x = c*y[][2] where c is a constant and x is a vector allow for mathematical procedures to be chained together very succinctly.

Looking at #6282 it seems that the conversation fizzled out. Has this been discussed and dismissed somewhere else or is there still a desire for this feature from others?

[carnott-snap]

Slices in Go are often referred to as reference types, because if you pass a slice to a function, and the function changes an element of the slice, then the caller sees the change. Similarly, if you take a slice of a slice, and then change an element of the subslice, the change is seen in the original slice.

If all we care about are that value changes are propagated to elements of the parent slice, that seems intuitive:

foo := [][]int {{1, 2, 3},
                {4, 5, 6},
                {7, 8, 9}}
inner := foo[][1]
inner[1] = 0
fmt.Println(foo)
// Output: [[1 2 3] [4 0 6] [7 8 9]]

But I guess that does not speak to the complexities of have a discontiguous backing array.

[seankhliao]

• strided (non contiguous) slices: proposal: spec: strided slices #13253
• vectors Proposal: Go2: Vector Basic Type - Similar to []T but with enhancements #35307

I seem to remember the scientific computing community (centered around gonum and gorgonia) wanting something similar, but the bar for language changes remains high

[ianlancetaylor]

You may also want to look at #13253.

[ianlancetaylor]

@JCCPort I don't think I would say that the conversation in #6282 fizzled out. The language change proposal was rejected as described at #6282 (comment).

I think there is definitely room for something to be done here. However, this is a complex area. Any change to the language here has to be very clear and has to work cleanly with the rest of the language.

In particular, if this new operation is going to make a copy of the slice, then I'm pretty skeptical that it should use the same indexing syntax that slice expressions use, since that indexing syntax very explicitly does not make a copy of the slice. And if we don't use the same syntax, it's worth asking whether it could simply be a function. And whether it is possible to write that function today.

[ianlancetaylor]

Per the discussion above, we aren't going to make this change as stated. To actually make this work, we would probably need to start with a new multi-dimensional matrix type, and figure out how to slice into that.

Leaving open for four weeks for final comments.

-- for @golang/proposal-review

[ianlancetaylor]

No further comments.