In principle I agree with the sentiment, in the sense this is what you'd
expect from other languages like Python.
However, slices are fundamentally different to maps in Go. Map values
contain a pointer to a mutable data structure (that's why you can't insert
into a zero map - you have to allocate the structure first). Slices are
structs that contain ptr/len/cap which are never mutated (although the data
elements pointed to by ptr may mutate, of course). To alter the len or cap
you have to create a new slice value to replace the old one. e.g.
a := []int{1,2,3}
a = a[0:0] // "clear"
So an in-place "clear" of a slice in the way you suggest, which alters the
existing len to zero, would have to take a pointer to a slice, not a plain
slice value.
TBH, I don't see the point of the new clear(slice) function. It clears
values up to len, not to cap:
https://go.dev/play/p/1N27HXHpEdZ?v=gotip
In which case, you might as well just write:
var z T // zero value
for i := 0; i < len(a); i++ {
a[i] = z
}
I've never felt the need to do this - certainly not enough to warrant a
built-in function. (I would allocate a new slice, and let the garbage
collector deal with the old one)
On Thursday, 6 July 2023 at 08:41:25 UTC+1 Henry wrote:
> 'make' allocates the required memory. 'len' returns the length. 'cap'
> returns the capacity. The underlying implementation may be different, but
> the concept is the same. There is no issue with those.
>
> It is common for a collection to have methods such as 'Add', 'Delete', and
> 'Clear'. The common interpretation of clearing a collection means removing
> all items from the collection and setting its length to zero. Clear works
> like that with map, but it does differently with slice. I would not say
> replacing the values in a slice with the default values as clearing. Maybe
> you can call that zeroing, but that's not clearing. Many people would
> expect after calling 'Clear(slice)' then the slice length should be zero.
> That's why I think the function is incoherent.
>
> On Thursday, July 6, 2023 at 1:17:39 PM UTC+7 Axel Wagner wrote:
>
>> Oh and FWIW: You are right (in my opinion) that the different things
>> `clear` does are, well, different. But note that clear is not the only
>> builtin for which that is the case. `make`, `len` and `cap` all do
>> different things (to varying degrees) on maps, slices and channels.
>> That's not necessarily a good reason to add more builtins that do
>> different things, but there is precedent.
>>
>> On Thu, Jul 6, 2023 at 8:14 AM Axel Wagner <axel.wa...@googlemail.com>
>> wrote:
>>
>>> On Thu, Jul 6, 2023 at 7:49 AM Henry <henry.ad...@gmail.com> wrote:
>>>
>>>> So, if I get this right, clear on map will result in map length equals
>>>> to zero, but clear on slice is only a value-zeroing operation and the
>>>> slice
>>>> length remains unchanged?
>>>
>>>
>>> That understanding is correct.
>>>
>>>
>>>> They seem like two different operations to me. I don't think that
>>>> built-in clear function is necessary. It doesn't seem like the function
>>>> has
>>>> a good reason to be there.
>>>>
>>>
>>> There is one thing that `clear` allows which is impossible without it
>>> and that's removing irreflexive keys (those that contain floating point
>>> types/elements/fields which are NaN) from a map.
>>>
>>> Whether that's a "good" reason is up for debate, of course. There has
>>> been quite a bit of that in the issue already:
>>> https://github.com/golang/go/issues/56351
>>>
>>>
>>>>
>>>> On Wednesday, July 5, 2023 at 3:54:43 PM UTC+7 Tharaneedharan
>>>> Vilwanathan wrote:
>>>>
>>>>> Hi Axel,
>>>>>
>>>>> Okay, that helps! Thanks for the details.
>>>>>
>>>>> Regards
>>>>> dharani
>>>>>
>>>>>
>>>>> On Wed, Jul 5, 2023 at 1:38 AM Axel Wagner <axel.wa...@googlemail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this has come up on the issue as well. Robert Griesemer provided an
>>>>>> explanation
>>>>>> <https://github.com/golang/go/issues/56351#issuecomment-1601751291>:
>>>>>>
>>>>>> If the argument type (the type of the argument provided to clear) is
>>>>>>> a type parameter (is of type parameter type), all types in its type set
>>>>>>> (in
>>>>>>> the type set of the constraint corresponding to the type parameter)
>>>>>>> must be
>>>>>>> maps or slices, and clear performs the operation corresponding to the
>>>>>>> actual type argument (corresponding to the type of the actual type
>>>>>>> argument
>>>>>>> with which the type parameter was instantiated).
>>>>>>
>>>>>>
>>>>>> That is, the sentence is about this situation:
>>>>>>
>>>>>> func Clear[T, any, S ~[]T](s S) {
>>>>>> clear(s)
>>>>>> }
>>>>>> func main() {
>>>>>> Clear(make([]int, 42))
>>>>>> }
>>>>>>
>>>>>> In this case, the type of s is S, which is a type parameter. So
>>>>>> `clear` performs the operation corresponding to the type argument - in
>>>>>> this
>>>>>> example []int.
>>>>>>
>>>>>> The sentence is a bit confusing (I've seen this question come up four
>>>>>> times now), so it probably should be clarified a bit.
>>>>>>
>>>>>> On Wed, Jul 5, 2023 at 9:06 AM Tharaneedharan Vilwanathan <
>>>>>> vdha...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Go 1.21 introduces a new clear() builtin function. I see this text
>>>>>>> in https://tip.golang.org/ref/spec#Clear:
>>>>>>>
>>>>>>> clear(t) type parameter see below
>>>>>>>
>>>>>>> If the argument type is a type parameter
>>>>>>> <https://tip.golang.org/ref/spec#Type_parameter_declarations>, all
>>>>>>> types in its type set must be maps or slices, and clear performs
>>>>>>> the operation corresponding to the actual type argument.
>>>>>>>
>>>>>>> I am not able to make sense of it. What does this mean? Any examples
>>>>>>> on the usage?
>>>>>>>
>>>>>>> Appreciate your help.
>>>>>>>
>>>>>>> Thanks
>>>>>>> dharani
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "golang-nuts" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to golang-nuts...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/golang-nuts/CAN-HoCn99D-m71aJr3DRzCJvk_c7h8OhG2O4wPC-1Wd2ruEYNg%40mail.gmail.com
>>>>>>>
>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/CAN-HoCn99D-m71aJr3DRzCJvk_c7h8OhG2O4wPC-1Wd2ruEYNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to golang-nuts...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/00e424f1-1a62-4183-8974-9a585960ce7dn%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/golang-nuts/00e424f1-1a62-4183-8974-9a585960ce7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/d3c721a4-ab88-446d-adcf-afe47a30bc32n%40googlegroups.com.
