[go-nuts] Re: I made a CLI tool, and I'm curious about your ideas

[long văn]

Impressive now let's see paul allen's gnt

Vào lúc 23:13:31 UTC+7 ngày Thứ Năm, 6 tháng 7, 2023, Alper Akca đã viết:

>
>
> [image: gnt.png]
> I am a beginner in Golang. I made a cli tool for creating a Go project. 
> You can easily create a new Go project using the 'gnt create projectName' 
> command. This command creates a 'bin', 'cmd/projectName/main.go' 
> directories and the go module file. Those who are good at golang can give 
> me ideas. GitHub repository link below:
> https://github.com/lnxwizard/gnt
>
>

-- 
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/db30158d-916a-4150-b8b8-1368941826f0n%40googlegroups.com.

[go-nuts] Re: Where are closure storing the captured variables ?

[jake...@gmail.com]

In addition to Axel's useful info, whenever you are interested in what 
escapes to the 'heap', it  can be helpful to build with escape analyses 
output. Try using "go build  -gcflags=-m". 

On Wednesday, July 5, 2023 at 8:35:52 PM UTC-4 chris...@meessen.net wrote:

> Hello,
>
> Closure need space to store the captured variables. According to 
> runtime.MemStats, it is not on the heap. Where are these variable stored ? 
> On the stack ?
>

-- 
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/9ed36da2-c466-420a-8724-fdd9f14455fan%40googlegroups.com.

Re: [go-nuts] CPU usage increasing day by day because of Cron

[Steven Hartland]

Your use of sync.WaitGroup looks strange. Typically you would expect to
call wg.Add(1) before a goroutine is started, wg.Done() before it returns
and wg.Wait() to ensure all goroutines have completed.
This doesn't seem to be what you're doing.

Consider restructuring to make best use of the goroutines (start them
first) with the WaitGroup being used to detect when they complete
processing all work items.

Other things, your switch on cronType is invariant so could result in
entries added to jobs never being processed hence wg.Wait blocking forever,
might be your leak.

Finally no need for bare return at the end of functions

Hope that helps.

On Mon, 3 Jul 2023 at 04:25, Rohit Rohit  wrote:

> I am running a cron  whose
> code is written in Golang ,and
> i am using mongoDb(version -4.4) as database, the cron runs after every 5
> minutes of interval, i have been noticing that when i start the cron within
> a week the cpu usage hikes from 0 to 60% or even more and i have to restart
> the cron service so that it shouldn’t effect the services of cron later on,
> which means that there’s an memory leak, resources are not being released
> properly, i’m not able to figure out what might be the reason, i have been
> using the single db connection for the whole cron let’s say a single cron
> is being for 2000 merchants. I’m running my cron with Worker pool using
> Buffered Channels. Below is the code which i am using for running my cron
> using worker pool
> func RunCronForDbNames(cronType, subsType string) {
> cronStatus := GetCronStatusConditions(cronType)
> if cronStatus {
> dbNames, _ := controller.GetDbNamesForCron(subsType, cronType)
> if len(dbNames) == 0 {
> return
> }
> client, ctx := ConnectDb("ip")
> defer client.Disconnect(ctx)
> cronDataChannel := make(chan view.CronChannelData, len(dbNames))
> var wg sync.WaitGroup
> startTime := time.Now().Unix()
> var cronChData view.CronChannelData
> cronChData.Database.Client = client
> cronChData.Database.Ctx = ctx
> cronChData.StartTime = startTime
> for _, dbName := range dbNames {
> isContinue := db.CheckGlobalCronStatus(cronType, dbNames)
> if !isContinue {
> continue
> }
> wg.Add(1)
> contextKeys := make(map[string]interface{})
> contextKeys["db_name"] = dbName
> contextKeys["role"] = ""
> var c gin.Context
> c.Keys = make(map[string]any)
> c.Keys = contextKeys
> cronChData.C = c
> cronChData.Database.MainDatabase = dbName
> cronDataChannel <- cronChData
> }
> close(cronDataChannel)
> for w := 1; w <= 10; w++ {
> go Worker(w, cronDataChannel, , cronType)
> }
> wg.Wait()
> }
> return
> }
>
> My worker is running with 10 workers at a time
> func Worker(id int, jobs <-chan view.CronChannelData, wg *sync.WaitGroup,
> cronType string) {
> switch cronType {
> case config.CompleteBookingCron:
> for job := range jobs {
> controller.CompleteBookingsCron(job, wg)
> }
> }
> return
> }
>
> In CompleteBookingsCron, I’m subtracting the WaitGroup using wg.Done() and
> marking the bookings as completed and send mails and Sms to our customers
> based on their settings. For sending Emails and Sms, go-routines are being
> used.
>
> Can someone help me find out what could be the reason for the increasing
> of cpu usage, what things should i follow in order to getting the resources
> freed up properly which should not increase the Cpu usage?
>
> --
> 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/2e700735-7c77-4d4b-95fb-f74599517b3fn%40googlegroups.com
> 
> .
>

-- 
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/CAA38peZwRfdNUYAgho8sjWJXMV1AAAJtT5KW1e5eM7Syhbz0zg%40mail.gmail.com.

Re: [go-nuts] Go 1.21 new builtin function clear()

['Axel Wagner' via golang-nuts]

On Thu 6. Jul 2023 at 09:41, Henry  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 
>> wrote:
>>
>>> On Thu, Jul 6, 2023 at 7:49 AM Henry  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 
> wrote:
>
>> Hi,
>>
>> this has come up on the issue as well. Robert Griesemer provided an
>> explanation
>> :
>>
>> 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 

Re: [go-nuts] Go 1.21 new builtin function clear()

[Brian Candler]

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  
>> wrote:
>>
>>> On Thu, Jul 6, 2023 at 7:49 AM Henry  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  
> wrote:
>
>> Hi,
>>
>> this has come up on the issue as well. Robert Griesemer provided an 
>> explanation 
>> :
>>
>> 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 

Re: [go-nuts] Go 1.21 new builtin function clear()

[Henry]

'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  
> wrote:
>
>> On Thu, Jul 6, 2023 at 7:49 AM Henry  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  
 wrote:

> Hi,
>
> this has come up on the issue as well. Robert Griesemer provided an 
> explanation 
> :
>
> 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 
>> , 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
>>  
>> 
>> .
>>

Re: [go-nuts] Why not return after calling http.Error()

[Gurunandan Bhat]

Thanks to everyone who reassured me.
I considered posting a set of links from the most popular Golang tutorials
that do not return after calling http.Error(), but then baulked

In any case, thanks once again to all in this thread.

Regards


On Wed, Jul 5, 2023 at 4:13 AM ben...@gmail.com  wrote:

>
> > Every example of http Handler that I have seen so far looks like this:
>
>
> Yes, that's definitely odd. I just grepped my Go source directory (which
> includes the Go compiler and stdlib and a bunch of other Go code), and
> almost all of them have a "return" on the next line. For example:
>
> $ rg --type=go --sort=path 'http\.Error\(' -A1
> ...
> pkgsite/internal/worker/server.go
> 319: http.Error(w, http.StatusText(code), code)
> 320- return
>
> -Ben
>
> --
> 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/7a727dd2-e39a-4414-b323-6f3ff2a27aa7n%40googlegroups.com
> 
> .
>

-- 
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/CAA_NO6i1XZN%2BpkGjEfeXubtZ_-xWzaaBDxQuo0GfaqdjH945EA%40mail.gmail.com.

Re: [go-nuts] how to close a child process after father process be killed

[Peter Galbavy]

Yes, setsid combined with cmd.Process.Release() works for me.

My local / specific needs code 
is 
https://github.com/ITRS-Group/cordial/blob/ad18bfbfa44eff1b9b66408394dd83749da25bb1/pkg/process/process.go#L64
 
which works well for everything I have thrown at it (on Linux).

On Wednesday, 5 July 2023 at 16:23:16 UTC+1 Brian Candler wrote:

> > Is there any way to create a child process that is detached from the 
> original cgroup using exec.Command?
> > I don't want my child process to be killed when the parent process dies.
>
> This might be an issue with process groups, not cgroups, in which case I 
> think Setsid is what you want, something like (untested):
>
> p.theCommand.SysProcAttr = {Setsid: true}
> err := p.theCommand.Start()
>
> I had a related problem: I wanted to make sure that when a timeout occurs, 
> I forcibly kill the child process and all its descendants. Solution was to 
> use Setsid, and then send the signal to the newly-formed process group:
> https://groups.google.com/g/golang-nuts/c/V1VccYYCp9o/m/rZRfhP_bCAAJ
>
>

-- 
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/035a010a-7ed6-40ed-b800-aaad4caf1d82n%40googlegroups.com.

Re: [go-nuts] Where are closure storing the captured variables ?

['Axel Wagner' via golang-nuts]

It depends a bit on escape analysis. I think the easiest way to reason
about it is to say that they are stored in the `func` value. If the `func`
value escapes, than so do the closed-over variables. If it doesn't (and the
closed-over variables are not otherwise escaped) they don't. At least to an
approximation.

The precise details of how closures are implemented are described in this
document:
https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub
I don't think anything material has changed since then.

On Thu, Jul 6, 2023 at 2:35 AM christo...@meessen.net <
christo...@meessen.net> wrote:

> Hello,
>
> Closure need space to store the captured variables. According to
> runtime.MemStats, it is not on the heap. Where are these variable stored ?
> On the stack ?
>
> --
> 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/dd7074fc-670d-4bb3-9b88-51af65d23d45n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfE8co8oxPw38cP2KurDtGawm75v4OkfMoj95ZR%2BeRge-w%40mail.gmail.com.

Re: [go-nuts] Go 1.21 new builtin function clear()

['Axel Wagner' via golang-nuts]

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 
wrote:

> On Thu, Jul 6, 2023 at 7:49 AM Henry  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 
>>> wrote:
>>>
 Hi,

 this has come up on the issue as well. Robert Griesemer provided an
 explanation
 :

 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
> , 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
> 
> .
>
 --
>> 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/00e424f1-1a62-4183-8974-9a585960ce7dn%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAEkBMfEsZ67fQEqOPMNEj%3Dgz5Y%2Bz5kgjPSHR8casGvt8YzaFuw%40mail.gmail.com.

Re: [go-nuts] Go 1.21 new builtin function clear()

['Axel Wagner' via golang-nuts]

On Thu, Jul 6, 2023 at 7:49 AM Henry  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 
>> wrote:
>>
>>> Hi,
>>>
>>> this has come up on the issue as well. Robert Griesemer provided an
>>> explanation
>>> :
>>>
>>> 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
 , 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
 
 .

>>> --
> 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/00e424f1-1a62-4183-8974-9a585960ce7dn%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfFZNkUQkJTnjwNjnPyHKd0hy%2BH%2BTg1L3wBLyG2WjUj5Tw%40mail.gmail.com.