[go-nuts] Replicating C unions with unsafe, arrays, and some constant arithmetic

I found this trick recently to replicate a C union in Go with unsafe.Sizeof, arrays, and some constant arithmetic. This lets you stack-allocate data that needs to be the max size of multiple other data types. So given a type A and B that you want to union, you can say const ASize = int64(unsafe

Re: [go-nuts] Maps with non-comparable keys

> I think it is unlikely to ever happen Yeah, it'd require a language change wouldn't it? Still, it'd be nice to take advantage of the runtime's map implementation without starting from scratch. > I tried my hand at it for fun Nice work! I like the use of map[uint64][]keyVal. -- You received

[go-nuts] Maps with non-comparable keys

Now that generics is coming along, is there an easy way to extend the builtin map type to use a non-comparable key type? For example, given this constraint type Key[T any] interface { Size() uint64 Hash(seed uint64) uint64 Equal(T) bool } and a type Foo like type Foo []

[go-nuts] Re: text/template: Can't call method/function with 0 results.

I believe functions are meant to be used as part of a pipeline, so having 1 value (+ error) makes it so the pipeline only stops execution on an error. I personally have not found a use for void functions, and it makes it easier to visualize the template execution model. On Friday, April 9, 2021 at

[go-nuts] Re: Should sync.Locker for sync.Once

Argh I messed up the title. It should be "Should sync.Once implement sync.Locker?" Oh well... On Friday, April 9, 2021 at 2:07:00 PM UTC-4 aind...@gmail.com wrote: > I've often been in situations where I've wanted to store and error or some > other signal once, but

[go-nuts] Should sync.Locker for sync.Once

I've often been in situations where I've wanted to store and error or some other signal once, but wanted reads to the stored value to be synchronized. I've often ended up introducing a secondary mutex, or reimplementing the slow path of sync.Once. This is a common pattern I see across many Go c

[go-nuts] Re: io/fs adapters?

m/perillo/45dfe7eb1c87e2d436574cab0d11221c > > > Manlio > > Il giorno domenica 28 marzo 2021 alle 10:06:21 UTC+2 seank...@gmail.com > ha scritto: > >> https://pkg.go.dev/testing/fstest ? >> >> On Sunday, March 28, 2021 at 5:09:12 AM UTC+2 aind...@gmail.com wrote: >> >>

[go-nuts] Re: Difference between cmd/compile/internal/syntax/parser.go and pkg/go/parser/parser.go

I won't speak for the maintainers of cmd/compile/internal/syntax, but packages in the standard library have to be backwards compatible with previous releases. This makes it difficult to make changes to its interface (possibly for performance reasons) and major re-architectures of its implementa

[go-nuts] io/fs adapters?

For testing library functions that accept fs.FS, I've been creating mock FS implementations. However, I'm surprised by the amount of code I've had to write for something like an FS with a single file in it. See below: *type singleFileFS struct {* *f stringFile* *}* *func (r singleFileFS) Op

Re: [go-nuts] Deep printing in the reflect package

her than format them? Akhil On Friday, September 4, 2020 at 4:24:23 PM UTC-4 Ian Lance Taylor wrote: > On Fri, Sep 4, 2020 at 1:11 PM aind...@gmail.com > wrote: > > > > Often on my team, Go programmers (particularly new ones) simply want > full visibility into a data structure

[go-nuts] Deep printing in the reflect package

Often on my team, Go programmers (particularly new ones) simply want full visibility into a data structure when debugging. For those who aren't familiar with pointers, seeing a hexadecimal number show up in a log can be really frustrating. I usually point them to https://github.com/davecgh/go-s