Open Binto86 opened 1 year ago
From my understanding there are two more or less conflicting viewpoints in regards to this issue. The viewpoint presented here is to construct array-like structures from a range, more or less a shorthand for a list/array literal, and the other is that of indexing/slicing. In my opinion, an inclusive..exclusive approach makes much more sense for purposes of indexing due to 0-indexing, while an inclusive..inclusive approach makes more sense for the list/array literal shorthand. I just think it'd feel weird to have 0..4
not include the 4
specified in the literal.
On the topic of indexing/slicing, there's also a whole host of open questions in that area, particularly whether range indexing should construct a completely new collection (ex. array[1..4]
produces a new array with the elements copied), or if it should produce a view/window of the collection (alike [ReadOnly]Span<T>
from C# or an operation akin to .Skip(lower).Take(upper - lower)
). It'd be useful for some situations to have slices of an array return a new array, although doing this in every situation could result in unwanted allocations where an equivalent to [ReadOnly]Span<T>
would be better suited. Returning a single IEnumerable<T>
-like structure which represents a view/window of the specified range of the collection on-demand is likely the simplest approach but again also the most limited.
Yeah, I think 0..4
to include 4
looks less confusing.
Range operator would be really neat adition for the language. It would construct a collection of ints from specified bounds. Question is if the bounds should be included or excluded from the constructed collection. In my opinion the left bound should be included and the right one excluded, so
0..4
would construct collection looking like this:[0, 1, 2, 3]
Proposed Syntax
The syntax could be
left_bound..right_bound