Re: [go-nuts] Re: Range over int

This is one feature that provides little value beyond saving a few keystrokes and looking slightly nice, but with potential of increased complexity when we need to implement more important features to the language down the road. This is my opinion. It shouldn't have been added, but what was

[go-nuts] Re: assert library with generics?

https://github.com/shoenig/test We've been using this for a couple years now, and it's been great. I am biased though, for obvious reasons. It makes use of the go-cmp library under the hood for creating legible diffs, and integrates well with protocmp for when you need to work with protobufs.

Re: [go-nuts] Re: pprof CPU profiles missing inlined frames

Got it. Sent from Yahoo Mail for iPhone On Sunday, February 18, 2024, 12:26 AM, Prashant V wrote: Ahh, I simplified the test too much, my mistake. I modified the example and verified that the profile does capture the inline function:      3.95s 79.16% 79.16%      3.95s 79.16%  main.modify

Re: [go-nuts] Equality of interface of an empty struct - why?

On Thu, Feb 22, 2024 at 10:39 AM Axel Wagner wrote: > > > > On Thu, Feb 22, 2024 at 6:06 PM burak serdar wrote: >> >> I don't think this case really applies here. I get that comparison of >> a==b may or may not be true. The problem is that if a==b at some point >> in a program, it should be the

Re: [go-nuts] Equality of interface of an empty struct - why?

I don't think this case really applies here. I get that comparison of a==b may or may not be true. The problem is that if a==b at some point in a program, it should be the case that a==b for all other cases in that same program. That is, if a==b, then interface{}(a)==interface{}(b), and vice

Re: [go-nuts] Equality of interface of an empty struct - why?

Creating an interface is not creating a pointer to a zero sized variable. a==b prints false. That means, a and b point to different locations Bar(a)==Bar(b) prints true. If a!=b, then Bar(a) must be different from Bar(b) On Thu, Feb 22, 2024 at 9:15 AM Axel Wagner wrote: > > If you expect

Re: [go-nuts] Equality of interface of an empty struct - why?

On Thu, Feb 22, 2024 at 9:00 AM Axel Wagner wrote: > > Note that in the Spec section I quoted above it says "Two distinct zero-size > variables may have the same address in memory" (emphasis mine). > There is no guarantee, that all zero-sized values have the same address > (otherwise, you'd get

Re: [go-nuts] Equality of interface of an empty struct - why?

The compiler can allocate the same address for empty structs, so I actually expected a==b to be true, not false. However, there's something more interesting going on here because: a := {} b := {} fmt.Printf("%t\n", *a == *b) fmt.Printf("%t\n", a == b) fmt.Printf("%p %p\n", a, b) x := Bar(a) y :=

Re: [go-nuts] Probable bug in database/sql

Thank you for the quick response! Let me elaborate a bit: my doubt arose from the hitEOF doc string which says that it's expected to be true when there are no more rows AND no errors where encountered; within Next, hitEOF is set to true when nextLocked's ok is false. That seems misleading to

Re: [go-nuts] Equality of interface of an empty struct - why?

>From the spec : > A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory. On Thu, Feb 22, 2024 at

[go-nuts] Equality of interface of an empty struct - why?

I'm confused by this output. It appears that the interface of two different pointers to an empty struct are equal. In all other cases, interface equality seems to be the pointer equality. What's going on in the empty struct case? ``` package main import "fmt" type Foo struct { } func (self

Re: [go-nuts] Unhappy with the official generics tutorial

On Thursday 22 February 2024 at 10:19:58 UTC+1 Jan Mercl wrote: On Thu, Feb 22, 2024 at 10:06 AM 'Carla Pfaff' via golang-nuts wrote: > This omission is notable considering "any" is among the most frequently used constraints in writing generic code. Interesting to know, I'd naively guess

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Hi! One more thing to keep in mind for the proposal: sometimes we need to merge two contexts. https://github.com/golang/go/issues/36503 https://github.com/golang/go/issues/57928 -- WBR, Alex. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Unhappy with the official generics tutorial

On Thu, Feb 22, 2024 at 10:06 AM 'Carla Pfaff' via golang-nuts wrote: > This omission is notable considering "any" is among the most frequently used > constraints in writing generic code. Interesting to know, I'd naively guess the opposite. Can you please share the source data set? Thank you.

Re: [go-nuts] Unhappy with the official generics tutorial

The feedback was not specific to the "SumIntsOrFloats" example in the tutorial. The tutorial fails to demonstrate any generic data structures utilizing the "[T any]" constraint or a function with an 'any' constraint, such as "slices.Clone[S ~[]E, E any](s S) S". This omission is notable

[go-nuts] assert library with generics?

Hi, anyone has a tip for a nice (small) "assert" test help library which uses generics for the "equals" and "not equals" functions? testify is the obvious library to use for tests, which works fine, but it would be nice to have something which uses generics here. Thanks! -- You received this

Re: [go-nuts] Unhappy with the official generics tutorial

I don't understand your feedback. How, exactly, should generics handle the `any` type? Documentation can always be improved but how would a generic function that accepts two `any` types perform addition of those "any" values? On Thu, Feb 22, 2024 at 12:01 AM 'Carla Pfaff' via golang-nuts <

[go-nuts] Unhappy with the official generics tutorial

The Go documentation, available at https://go.dev/doc/, features only one tutorial dedicated to generics, found at https://go.dev/doc/tutorial/generics. This tutorial lacks any examples employing the 'any' constraint, nor does it mention it. Instead, it begins with the use of an 'int64 |