Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
spec: an uninitialized slice (and other types) is nil, yet a slice variable is initialized to its zero (nil) value #20186
I have two small issues with the definition of a slice type:
This is not true of a
This is not true of a slice whose capacity has been explicitly reduced. This is easily fixed by removing the explicit definition of capacity here and then, in the section on slice expressions, explicitly saying that the capacity of the slice
In a similar vein:
I think the spec basically treats "uninitialized" and "nil" as equivalent. In particular, it does specify that a slice-literal,
However, especially with the issues originally brought up here, I don't really feel confident to judge whether these actually yield consistent results…
@alercah Thanks for this issue, I finally took a look at this. I think you're absolutely right about the initialization problem. In fact, the spec says elsewhere that variables which have no initialization expression are initialized to their zero value, which would be
The same is true for pointers (an uninitialized pointer is
Regarding the capacity of an explicitly reduced slice: You're right that in the implementation the length of the array beyond the slice is (may be) longer than what the reduced capacity claims it is, but there's no way to access that part of the array from that slice, so it might as well not exist (and theoretically, one could imagine a system that actually shrinks that underlying array). So I'm not sure there's much to do here.
Retitling this issue to be clearer what it's about.
Here the maximum element index is considered in the abstract - it's the highest index of any element present. Even if there are literal element indices, not all elements are required to have one, and the element with the largest actual index may not have literally an index in the source. But perhaps this can be formulated a bit clearer.
You're correct, in a mathematically exact sense this is underspecified. Maybe this can be written down w/o the spec coming across overly pedantic.
Fair enough. I'd say, this is similar to your 2nd point. We've been trying to keep the spec reasonably readable, probably at the cost of some precision.
Will try to address when we try to fix this issue. Not urgent.
With respect to the second issue, I don't think there's nothing to be done. Perhaps focusing on the language about the underlying array was a mistake there. Regardless, though, slice expressions that don't explicitly specify the capacity of the resulting slice and I believe that they should.