[go-nuts] Is it necessary to change the behavior of maps.Keys and maps.Values?
Since the x/exp/maps era, I have used maps.Keys and maps.Values extensively. They are very useful and avoid users from doing loop iterations. I remember that they were added to the standard library, but I used maps.Keys in the latest go version and was surprised that it could not compile. By looking at the source code, I found that their behavior seemed to have changed for iter? Related discussions: https://github.com/golang/go/issues/57436 https://github.com/golang/go/issues/61538 Maybe I have limited information and less knowledge than the members of the go team, but if it is to support the functions of the iter package, why not add two new function names, such as maps.KeysIter and maps.ValuesIter, instead of changing the behavior of the previous method? In addition, how do you deal with the scenarios previously handled by maps.Keys? Do you do it manually with for ..range..append, or use golang.org/x/exp/maps? Is it necessary to propose a proposal to add these two methods back to the standard library, but with different names? -- 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 visit https://groups.google.com/d/msgid/golang-nuts/4f95be15-1a7d-4cb8-a19d-eb33a1736d68n%40googlegroups.com.
Re: [go-nuts] Is it necessary to change the behavior of maps.Keys and maps.Values?
Hi, If you want a slice in lieu of an iterator, you can use the slices package and its Collect function : https://pkg.go.dev/slices#Collect hth, -a Dec 24, 2024 05:08:01 fliter : > > > Since the x/exp/maps era, I have used maps.Keys and maps.Values > extensively. They are very useful and avoid users from doing loop > iterations. > > I remember that they were added to the standard library, but I used maps.Keys > in the latest go version and was surprised that it could not compile. By > looking at the source code, I found that their behavior seemed to have > changed for iter? > > Related discussions: > > https://github.com/golang/go/issues/57436 > > https://github.com/golang/go/issues/61538 > > Maybe I have limited information and less knowledge than the members of the > go team, but if it is to support the functions of the iter package, why not > add two new function names, such as maps.KeysIter and maps.ValuesIter, > instead of changing the behavior of the previous method? > > In addition, how do you deal with the scenarios previously handled by > maps.Keys? Do you do it manually with for ..range..append, or use > golang.org/x/exp/maps? Is it necessary to propose a proposal to add these two > methods back to the standard library, but with different names? > > -- > 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 visit > https://groups.google.com/d/msgid/golang-nuts/4f95be15-1a7d-4cb8-a19d-eb33a1736d68n%40googlegroups.com[https://groups.google.com/d/msgid/golang-nuts/4f95be15-1a7d-4cb8-a19d-eb33a1736d68n%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 visit https://groups.google.com/d/msgid/golang-nuts/f766e531-793e-4bcb-9747-a28490c7b828%40sbinet.org. signature.asc Description: PGP signature
[go-nuts] using runtime cgo.Handle passing chan type
Hi, I need to use CGO to call a C function in a Go program, where the parameter type is a void pointer. Now I need to pass a struct to the C function, and the struct contains a channel. Additionally, I have a Go callback function that the C function will call, using the data from this struct. The problem is that when I try to access this struct in the Go callback function, I can't retrieve the data. Is this because it is not supported to pass a channel type to C? The documentation I referred to: https://pkg.go.dev/runtime/cgo#Handle https://groups.google.com/g/golang-nuts/c/PLSIN5jmzpM/m/L9bYGl3oAQAJ -- 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 visit https://groups.google.com/d/msgid/golang-nuts/14bd925b-19ca-4644-9200-315b99dd5029n%40googlegroups.com.
Re: [go-nuts] using runtime cgo.Handle passing chan type
On Mon, Dec 23, 2024 at 8:29 AM 'Red' via golang-nuts wrote: > > I need to use CGO to call a C function in a Go program, where the parameter > type is a void pointer. Now I need to pass a struct to the C function, and > the struct contains a channel. Additionally, I have a Go callback function > that the C function will call, using the data from this struct. The problem > is that when I try to access this struct in the Go callback function, I can't > retrieve the data. Is this because it is not supported to pass a channel type > to C? > > The documentation I referred to: > > https://pkg.go.dev/runtime/cgo#Handle > https://groups.google.com/g/golang-nuts/c/PLSIN5jmzpM/m/L9bYGl3oAQAJ You can pass a channel to C code using a cgo.Handle. I don't know what you mean when you say "I can't retrieve the data." Can you show a small self-contained example that demonstrates the problem? Ian -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV%3DrHRtwgMS-Og_wgWjn_i8aQ4fTdLE8iVSL8Fu9wYo%2Bw%40mail.gmail.com.
