On Thu 6. Jul 2023 at 09:41, Henry <henry.adisuma...@gmail.com> wrote:
> 'make' allocates the required memory. Does it? What about channels and maps? 'len' returns the length. What’s the “length” of a channel? What’s the “length” of a map? 'cap' returns the capacity. For maps? These questions are rhetorical, for what it’s worth. I understand how the language works, I just try to illustrate that brushing aside these differences is like me saying “clear clears it’s argument”. 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. > Note that this has been discussed on the issue, as far as I remember. Nothing of what you say is wrong. But there are counterpoints. For example, there is no precedence for a function (prefects red or not) that takes a slice and modifies it. For example, append has to return a modified slice. So I don’t think it really is right to say “people would expect the length of a to be zero after clear(a)”. I think they would be differently surprised. But really, I’m not super sold on the final semantics of clear either. But these questions have been considered. > 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 > <https://groups.google.com/d/msgid/golang-nuts/83de49c5-4624-4863-ab5b-fccc34565e32n%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/CAEkBMfE1M5AMGkw5zkzdWgte%3DBhWZCuc84OvKqZvf4EyZJqP-w%40mail.gmail.com.
