'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/83de49c5-4624-4863-ab5b-fccc34565e32n%40googlegroups.com.
