date:20240222

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

2024-02-22 Thread Henry

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 done is done. There is nothing we can do about it now. 

On Sunday, February 18, 2024 at 5:38:25 AM UTC+7 poweredb...@gmail.com 
wrote:

> I agree with you.
>
>
> Powered By Citizen 
>
> On Saturday, February 17, 2024, 1:19 AM, Kurtis Rader <
> kra...@skepticism.us> wrote:
>
> It's not just changing `k` inside the loop body that makes the 
> transformation invalid -- your observation also applies to modifying `i` 
> inside the loop body. Modifying either variable inside the loop body is 
> extremely rare in my experience and doing so warrants a "dragons be here" 
> comment. Still, your point is valid and anyone applying such a 
> transformation should carefully evaluate the body of each loop to see if 
> either variable might be modified by the loop body. Obviously it would be 
> nice if a tool automated that analysis and transformation but I'm not going 
> to hold my breath waiting for someone to implement that tool.
>
> On Fri, Feb 16, 2024 at 11:06 PM Patrick Smith  wrote:
>
> On Fri, Feb 16, 2024 at 10:27 PM Amnon  wrote:
>
> But now it is out, I think it is great, and have run 
> perl -pi -e 's/for (\w+) := 0; \1 < ([\w()]+); \1\+\+/for \1 := range 
> \2/' $(git grep -l for) over my entire codebase to use it everywhere.
>
>
> You know your own codebase, and maybe this was safe for you to do. But in 
> general, blindly applying such a blanket change has the potential to cause 
> bugs, as these two are not always equivalent:
>
> for i := range k
> for i := 0; i < k; i++ 
>
> In particular, if k is changed inside the loop they may be very different. 
> https://go.dev/play/p/kAHcmu7377I
>
> (Yes, many people, myself included, would consider changing k inside such 
> a loop to be bad coding style. But "bad style" doesn't mean it's not going 
> to be done.)
>
> -- 
> 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/CAADvV_trGNxeLUma722wk-JOGnz42fJqM8%3DVZ36TKpr5s-%3DmOQ%40mail.gmail.com
>  
> 
> .
>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> -- 
> 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/CABx2%3DD9Hyjj_N9KjY6XfFH0ZUt55f27VCcZQSj_DyX36gzrX1g%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/8ecbbbad-4881-4648-8e0e-347fbd0b6057n%40googlegroups.com.

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

2024-02-22 Thread Seth Hoenig

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. 

On Thursday, February 22, 2024 at 2:20:57 AM UTC-6 Harmen wrote:

> 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 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/61fe55d0-8e3d-4dc0-a12e-00f48dbc7856n%40googlegroups.com.

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

2024-02-22 Thread cluffjames825

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 (inline)
     1.04s 20.84%   100%      4.99s   100%  main.main

Thank youOn Saturday 17 February 2024 at 09:27:03 UTC-8 Keith Randall wrote:

This is a problem with your test. pprof is correct here. Since you never use n, 
when double is inlined its body is compiled completely away.
On Thursday, February 15, 2024 at 10:18:07 PM UTC-8 Prashant V wrote:

Is it expected that CPU profiles taken with pprof don't include inlined frames?
With a simple repro, when the `double` function has `go:noinline`, then the 
pprof shows the double function as expected,
     3.34s 67.07% 67.07%      4.98s   100%  main.main
     1.64s 32.93%   100%      1.64s 32.93%  main.double

However, when the noinline directive is removed, the double function isn't 
shown, only the main function is:
     4.99s   100%   100%      4.99s   100%  main.main

Is this an expected limitation of pprof profiles, or this a bug that I should 
report?
Thanks



-- 
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/055b81a1-9890-40af-b359-c440769f2d89n%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/1413677560.3362189.1708657603230%40mail.yahoo.com.

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

2024-02-22 Thread burak serdar

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 case that a==b for all other cases in
>> that same program.
>
>
> Why? I mean, I get that it makes sense intuitively, but how does this follow 
> from the spec? That sentence says "a comparison of two pointers to zero sized 
> values may or may not be true". It does not qualify that statement in any way.

We are comparing two interfaces containing pointers to zero-size
structs. If those pointers are not equal, then the interfaces should
not be equal as well.

Maybe the spec should be clarified to say "for a compilation of a
program, two pointers to zero-size variables may or may not be equal",
because otherwise it implies that if you have

x:= a==b
y:= a==b

x may or may not be true. If a==b, then that should hold for every
execution of that program, and throughout the program.


>
>>
>> That is, if a==b, then
>> interface{}(a)==interface{}(b), and vice versa. But what we have here
>> is a!=b but interface{}(a)==interface{}(b)
>>
>> On Thu, Feb 22, 2024 at 9:50 AM Axel Wagner
>>  wrote:
>> >
>> > Hm actually, the spec allows for this, technically speaking: 
>> > https://go.dev/ref/spec#Comparison_operators
>> >
>> > > Pointers to distinct zero-size variables may or may not be equal.
>> >
>> > Arguably, this genuinely would allow comparison of pointers to zero-sized 
>> > variables to have any behavior whatsoever (including being random). But it 
>> > certainly is confusing.
>> >
>> >
>> > On Thu, Feb 22, 2024 at 5:46 PM Axel Wagner 
>> >  wrote:
>> >>
>> >> I see. Sorry, I was jumping to conclusions and didn't quite get what you 
>> >> mean. That is my fault.
>> >>
>> >> I agree that this looks confusing and is arguably a bug. I filed 
>> >> https://github.com/golang/go/issues/65878, thanks for pointing it out.
>> >>
>> >> On Thu, Feb 22, 2024 at 5:20 PM burak serdar  wrote:
>> >>>
>> >>> 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 that, you are misreading the spec. There is no guarantee 
>> >>> > of any behavior here. An implementation is allowed to flip a coin, 
>> >>> > every time you create a pointer to a zero-sized variable, and either 
>> >>> > return a unique pointer or a singleton. I think you may assume that &a 
>> >>> > == &a, always. But apart from that, who knows.
>> >>> >
>> >>> > Zero-sized variables *may* have the same address. They don't *have* to.
>> >>> >
>> >>> > On Thu, Feb 22, 2024 at 5:12 PM burak serdar  
>> >>> > wrote:
>> >>> >>
>> >>> >> 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 into inefficiencies when taking the 
>> >>> >> > address of a zero-sized field in a larger struct, or when 
>> >>> >> > converting a zero-capacity slice into an array-pointer). But it is 
>> >>> >> > allowed.
>> >>> >> > If you require two pointers returned from different code paths to 
>> >>> >> > be different, for correctness, then you have to make them point at 
>> >>> >> > something that has non-zero size. Otherwise, all potential 
>> >>> >> > combinations are valid according to the spec.
>> >>> >>
>> >>> >> Yes. But in that case, you'd expect either  a==b and Bar(a)==Bar(b) to
>> >>> >> be both true, or both false. In this case, one is true and the other
>> >>> >> is not.
>> >>> >>
>> >>> >>
>> >>> >> >
>> >>> >> > On Thu, Feb 22, 2024 at 4:53 PM burak serdar  
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> 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 := &Foo{}
>> >>> >> >> b := &Foo{}
>> >>> >> >> fmt.Printf("%t\n", *a == *b)
>> >>> >> >> fmt.Printf("%t\n", a == b)
>> >>> >> >> fmt.Printf("%p %p\n", a, b)
>> >>> >> >> x := Bar(a)
>> >>> >> >> y := Bar(b)
>> >>> >> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >>> >> >> fmt.Printf("%t\n", x == y)
>> >>> >> >>
>> >>> >> >> Prints:
>> >>> >> >>
>> >>> >> >> true
>> >>> >> >> true
>> >>> >> >> 0x58e360 0x58e360 // Note that a and be are pointing to the same 
>> >>> >> >> address
>> >>> >> >> true
>> >>> >> >> true
>> >>> >> >>
>> >>> >> >>
>>

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

2024-02-22 Thread burak serdar

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 versa. But what we have here
is a!=b but interface{}(a)==interface{}(b)

On Thu, Feb 22, 2024 at 9:50 AM Axel Wagner
 wrote:
>
> Hm actually, the spec allows for this, technically speaking: 
> https://go.dev/ref/spec#Comparison_operators
>
> > Pointers to distinct zero-size variables may or may not be equal.
>
> Arguably, this genuinely would allow comparison of pointers to zero-sized 
> variables to have any behavior whatsoever (including being random). But it 
> certainly is confusing.
>
>
> On Thu, Feb 22, 2024 at 5:46 PM Axel Wagner  
> wrote:
>>
>> I see. Sorry, I was jumping to conclusions and didn't quite get what you 
>> mean. That is my fault.
>>
>> I agree that this looks confusing and is arguably a bug. I filed 
>> https://github.com/golang/go/issues/65878, thanks for pointing it out.
>>
>> On Thu, Feb 22, 2024 at 5:20 PM burak serdar  wrote:
>>>
>>> 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 that, you are misreading the spec. There is no guarantee of 
>>> > any behavior here. An implementation is allowed to flip a coin, every 
>>> > time you create a pointer to a zero-sized variable, and either return a 
>>> > unique pointer or a singleton. I think you may assume that &a == &a, 
>>> > always. But apart from that, who knows.
>>> >
>>> > Zero-sized variables *may* have the same address. They don't *have* to.
>>> >
>>> > On Thu, Feb 22, 2024 at 5:12 PM burak serdar  wrote:
>>> >>
>>> >> 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 into inefficiencies when taking the 
>>> >> > address of a zero-sized field in a larger struct, or when converting a 
>>> >> > zero-capacity slice into an array-pointer). But it is allowed.
>>> >> > If you require two pointers returned from different code paths to be 
>>> >> > different, for correctness, then you have to make them point at 
>>> >> > something that has non-zero size. Otherwise, all potential 
>>> >> > combinations are valid according to the spec.
>>> >>
>>> >> Yes. But in that case, you'd expect either  a==b and Bar(a)==Bar(b) to
>>> >> be both true, or both false. In this case, one is true and the other
>>> >> is not.
>>> >>
>>> >>
>>> >> >
>>> >> > On Thu, Feb 22, 2024 at 4:53 PM burak serdar  
>>> >> > wrote:
>>> >> >>
>>> >> >> 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 := &Foo{}
>>> >> >> b := &Foo{}
>>> >> >> fmt.Printf("%t\n", *a == *b)
>>> >> >> fmt.Printf("%t\n", a == b)
>>> >> >> fmt.Printf("%p %p\n", a, b)
>>> >> >> x := Bar(a)
>>> >> >> y := Bar(b)
>>> >> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>>> >> >> fmt.Printf("%t\n", x == y)
>>> >> >>
>>> >> >> Prints:
>>> >> >>
>>> >> >> true
>>> >> >> true
>>> >> >> 0x58e360 0x58e360 // Note that a and be are pointing to the same 
>>> >> >> address
>>> >> >> true
>>> >> >> true
>>> >> >>
>>> >> >>
>>> >> >> But:
>>> >> >> a := &Foo{}
>>> >> >> b := &Foo{}
>>> >> >> fmt.Printf("%t\n", *a == *b)
>>> >> >> fmt.Printf("%t\n", a == b)
>>> >> >> //fmt.Printf("%p %p\n", a, b)  // Comment out the print
>>> >> >> x := Bar(a)
>>> >> >> y := Bar(b)
>>> >> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>>> >> >> fmt.Printf("%t\n", x == y)
>>> >> >>
>>> >> >>
>>> >> >> Prints:
>>> >> >>
>>> >> >> true
>>> >> >> false
>>> >> >> true
>>> >> >> true
>>> >> >>
>>> >> >>
>>> >> >> On Thu, Feb 22, 2024 at 3:56 AM Brien Colwell  
>>> >> >> wrote:
>>> >> >> >
>>> >> >> > 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 *Foo) Hello() {
>>> >> >> > }
>>> >> >> >
>>> >> >> > type FooWithValue struct {
>>> >> >> > A int
>>> >> >> > }
>>> >> >> >
>>> >> >> > func (self *FooWithValue) Hello() {
>>>

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

2024-02-22 Thread burak serdar

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 that, you are misreading the spec. There is no guarantee of any 
> behavior here. An implementation is allowed to flip a coin, every time you 
> create a pointer to a zero-sized variable, and either return a unique pointer 
> or a singleton. I think you may assume that &a == &a, always. But apart from 
> that, who knows.
>
> Zero-sized variables *may* have the same address. They don't *have* to.
>
> On Thu, Feb 22, 2024 at 5:12 PM burak serdar  wrote:
>>
>> 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 into inefficiencies when taking the address of a 
>> > zero-sized field in a larger struct, or when converting a zero-capacity 
>> > slice into an array-pointer). But it is allowed.
>> > If you require two pointers returned from different code paths to be 
>> > different, for correctness, then you have to make them point at something 
>> > that has non-zero size. Otherwise, all potential combinations are valid 
>> > according to the spec.
>>
>> Yes. But in that case, you'd expect either  a==b and Bar(a)==Bar(b) to
>> be both true, or both false. In this case, one is true and the other
>> is not.
>>
>>
>> >
>> > On Thu, Feb 22, 2024 at 4:53 PM burak serdar  wrote:
>> >>
>> >> 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 := &Foo{}
>> >> b := &Foo{}
>> >> fmt.Printf("%t\n", *a == *b)
>> >> fmt.Printf("%t\n", a == b)
>> >> fmt.Printf("%p %p\n", a, b)
>> >> x := Bar(a)
>> >> y := Bar(b)
>> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >> fmt.Printf("%t\n", x == y)
>> >>
>> >> Prints:
>> >>
>> >> true
>> >> true
>> >> 0x58e360 0x58e360 // Note that a and be are pointing to the same address
>> >> true
>> >> true
>> >>
>> >>
>> >> But:
>> >> a := &Foo{}
>> >> b := &Foo{}
>> >> fmt.Printf("%t\n", *a == *b)
>> >> fmt.Printf("%t\n", a == b)
>> >> //fmt.Printf("%p %p\n", a, b)  // Comment out the print
>> >> x := Bar(a)
>> >> y := Bar(b)
>> >> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >> fmt.Printf("%t\n", x == y)
>> >>
>> >>
>> >> Prints:
>> >>
>> >> true
>> >> false
>> >> true
>> >> true
>> >>
>> >>
>> >> On Thu, Feb 22, 2024 at 3:56 AM Brien Colwell  wrote:
>> >> >
>> >> > 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 *Foo) Hello() {
>> >> > }
>> >> >
>> >> > type FooWithValue struct {
>> >> > A int
>> >> > }
>> >> >
>> >> > func (self *FooWithValue) Hello() {
>> >> > }
>> >> >
>> >> > type Bar interface {
>> >> > Hello()
>> >> > }
>> >> >
>> >> > func main() {
>> >> > a := &Foo{}
>> >> > b := &Foo{}
>> >> > fmt.Printf("%t\n", *a == *b)
>> >> > fmt.Printf("%t\n", a == b)
>> >> > fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >> >
>> >> > c := &FooWithValue{A: 1}
>> >> > d := &FooWithValue{A: 1}
>> >> > fmt.Printf("%t\n", *c == *d)
>> >> > fmt.Printf("%t\n", c == d)
>> >> > fmt.Printf("%t\n", Bar(c) == Bar(d))
>> >> > }
>> >> > ```
>> >> >
>> >> > Prints (emphasis added on the strange case):
>> >> >
>> >> > ```
>> >> > true
>> >> > false
>> >> > **true**
>> >> > true
>> >> > false
>> >> > false
>> >> > ```
>> >> >
>> >> >
>> >> > --
>> >> > 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/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%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/CAMV2Rqrq21ymUJ00ni_JV%3Dkv6itqZg51GoWM5zJNjcGU1BKcuA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsu

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

2024-02-22 Thread burak serdar

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 into inefficiencies when taking the address of a 
> zero-sized field in a larger struct, or when converting a zero-capacity slice 
> into an array-pointer). But it is allowed.
> If you require two pointers returned from different code paths to be 
> different, for correctness, then you have to make them point at something 
> that has non-zero size. Otherwise, all potential combinations are valid 
> according to the spec.

Yes. But in that case, you'd expect either  a==b and Bar(a)==Bar(b) to
be both true, or both false. In this case, one is true and the other
is not.


>
> On Thu, Feb 22, 2024 at 4:53 PM burak serdar  wrote:
>>
>> 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 := &Foo{}
>> b := &Foo{}
>> fmt.Printf("%t\n", *a == *b)
>> fmt.Printf("%t\n", a == b)
>> fmt.Printf("%p %p\n", a, b)
>> x := Bar(a)
>> y := Bar(b)
>> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> fmt.Printf("%t\n", x == y)
>>
>> Prints:
>>
>> true
>> true
>> 0x58e360 0x58e360 // Note that a and be are pointing to the same address
>> true
>> true
>>
>>
>> But:
>> a := &Foo{}
>> b := &Foo{}
>> fmt.Printf("%t\n", *a == *b)
>> fmt.Printf("%t\n", a == b)
>> //fmt.Printf("%p %p\n", a, b)  // Comment out the print
>> x := Bar(a)
>> y := Bar(b)
>> fmt.Printf("%t\n", Bar(a) == Bar(b))
>> fmt.Printf("%t\n", x == y)
>>
>>
>> Prints:
>>
>> true
>> false
>> true
>> true
>>
>>
>> On Thu, Feb 22, 2024 at 3:56 AM Brien Colwell  wrote:
>> >
>> > 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 *Foo) Hello() {
>> > }
>> >
>> > type FooWithValue struct {
>> > A int
>> > }
>> >
>> > func (self *FooWithValue) Hello() {
>> > }
>> >
>> > type Bar interface {
>> > Hello()
>> > }
>> >
>> > func main() {
>> > a := &Foo{}
>> > b := &Foo{}
>> > fmt.Printf("%t\n", *a == *b)
>> > fmt.Printf("%t\n", a == b)
>> > fmt.Printf("%t\n", Bar(a) == Bar(b))
>> >
>> > c := &FooWithValue{A: 1}
>> > d := &FooWithValue{A: 1}
>> > fmt.Printf("%t\n", *c == *d)
>> > fmt.Printf("%t\n", c == d)
>> > fmt.Printf("%t\n", Bar(c) == Bar(d))
>> > }
>> > ```
>> >
>> > Prints (emphasis added on the strange case):
>> >
>> > ```
>> > true
>> > false
>> > **true**
>> > true
>> > false
>> > false
>> > ```
>> >
>> >
>> > --
>> > 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/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%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/CAMV2Rqrq21ymUJ00ni_JV%3Dkv6itqZg51GoWM5zJNjcGU1BKcuA%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/CAMV2RqrRNT9CmWbhMYTOV4fmnAvLULTw0cVe%3Dd4adfTLO6gQoA%40mail.gmail.com.

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

2024-02-22 Thread burak serdar

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 := &Foo{}
b := &Foo{}
fmt.Printf("%t\n", *a == *b)
fmt.Printf("%t\n", a == b)
fmt.Printf("%p %p\n", a, b)
x := Bar(a)
y := Bar(b)
fmt.Printf("%t\n", Bar(a) == Bar(b))
fmt.Printf("%t\n", x == y)

Prints:

true
true
0x58e360 0x58e360 // Note that a and be are pointing to the same address
true
true


But:
a := &Foo{}
b := &Foo{}
fmt.Printf("%t\n", *a == *b)
fmt.Printf("%t\n", a == b)
//fmt.Printf("%p %p\n", a, b)  // Comment out the print
x := Bar(a)
y := Bar(b)
fmt.Printf("%t\n", Bar(a) == Bar(b))
fmt.Printf("%t\n", x == y)


Prints:

true
false
true
true


On Thu, Feb 22, 2024 at 3:56 AM Brien Colwell  wrote:
>
> 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 *Foo) Hello() {
> }
>
> type FooWithValue struct {
> A int
> }
>
> func (self *FooWithValue) Hello() {
> }
>
> type Bar interface {
> Hello()
> }
>
> func main() {
> a := &Foo{}
> b := &Foo{}
> fmt.Printf("%t\n", *a == *b)
> fmt.Printf("%t\n", a == b)
> fmt.Printf("%t\n", Bar(a) == Bar(b))
>
> c := &FooWithValue{A: 1}
> d := &FooWithValue{A: 1}
> fmt.Printf("%t\n", *c == *d)
> fmt.Printf("%t\n", c == d)
> fmt.Printf("%t\n", Bar(c) == Bar(d))
> }
> ```
>
> Prints (emphasis added on the strange case):
>
> ```
> true
> false
> **true**
> true
> false
> false
> ```
>
>
> --
> 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/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%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/CAMV2Rqrq21ymUJ00ni_JV%3Dkv6itqZg51GoWM5zJNjcGU1BKcuA%40mail.gmail.com.

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

2024-02-22 Thread Marco De Zio

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 me as it's set to true 
even if "Rows is NOT pointing to a valid data" (or whatever error the 
driver's Next may return).

Now that I've also looked a bit more into it I can see that it's not really 
buggy as Rows.Err will still report the right error and hitEOF is used only 
for the closing context error, but that code still smell bad to me due to 
that description.

Il giorno giovedì 22 febbraio 2024 alle 02:56:37 UTC+1 Ian Lance Taylor ha 
scritto:

> On Wed, Feb 21, 2024 at 4:27 PM Marco De Zio  wrote:
> >
> > It seems to me that the second flag returned by Rows.nextLocked is 
> wrongly interpreted by Rows.Next as it sets rs.hitEOF = true when ok is 
> false; also Rows.nextLocked should set ok to true in some of the cases 
> where right now returns false.
> >
> > Reference in code: 
> https://github.com/golang/go/blob/507d1b22f4b58ac68841582d0c2c0ab6b20e5a98/src/database/sql/sql.go#L3027
> >
> > Am I wrong ?
>
> The "ok" result of nextLocked is intended to report whether, when the
> method returns, the Rows is pointing at valid data. The "doClose"
> result reports whether the Rows should be closed. Given that
> understanding, the behavior of Next looks reasonable to me.
>
> As it happens when the current implementation returns "doClose" as
> true, it always returns "ok" as false. So the test "if doClose &&
> !ok" is not strictly necessary; it could be replaced with "if
> doClose". But the current code doesn't seem wrong to me.
>
> Can you show a code sequence that seems buggy to you?
>
> 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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7f3a7419-653a-4b75-8e7a-f5174667feb9n%40googlegroups.com.

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

2024-02-22 Thread 'Axel Wagner' via golang-nuts

>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 11:56 AM Brien Colwell  wrote:

> 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 *Foo) Hello() {
> }
>
> type FooWithValue struct {
> A int
> }
>
> func (self *FooWithValue) Hello() {
> }
>
> type Bar interface {
> Hello()
> }
>
> func main() {
> a := &Foo{}
> b := &Foo{}
> fmt.Printf("%t\n", *a == *b)
> fmt.Printf("%t\n", a == b)
> fmt.Printf("%t\n", Bar(a) == Bar(b))
>
> c := &FooWithValue{A: 1}
> d := &FooWithValue{A: 1}
> fmt.Printf("%t\n", *c == *d)
> fmt.Printf("%t\n", c == d)
> fmt.Printf("%t\n", Bar(c) == Bar(d))
> }
> ```
>
> Prints (emphasis added on the strange case):
>
> ```
> true
> false
> **true**
> true
> false
> false
> ```
>
>
> --
> 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/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%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/CAEkBMfGOHMd%3D4R2QC%2BRKTimBZq%3DThsz8n2wORxYFxQMRgtyCsQ%40mail.gmail.com.

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

2024-02-22 Thread Brien Colwell

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 *Foo) Hello() {
}

type FooWithValue struct {
A int
}

func (self *FooWithValue) Hello() {
}

type Bar interface {
Hello()
}

func main() {
a := &Foo{}
b := &Foo{}
fmt.Printf("%t\n", *a == *b)
fmt.Printf("%t\n", a == b)
fmt.Printf("%t\n", Bar(a) == Bar(b))

c := &FooWithValue{A: 1}
d := &FooWithValue{A: 1}
fmt.Printf("%t\n", *c == *d)
fmt.Printf("%t\n", c == d)
fmt.Printf("%t\n", Bar(c) == Bar(d))
}
```

Prints (emphasis added on the strange case):

```
true
false
**true**
true
false
false
```


-- 
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/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%40googlegroups.com.

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

2024-02-22 Thread 'Carla Pfaff' via golang-nuts

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 the opposite. Can you please 
share the source data set? Thank you.


In the standard library, the most notable packages that add generic 
functions are slices  and maps 
. Almost all of their functions feature an 'any' 
constraint. Same for other generic additions to the standard library such 
as atomic.Pointer, reflect.TypeFor, and sync.OnceValue.

-- 
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/7e0656cf-876c-4a82-9760-40923261d722n%40googlegroups.com.

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

2024-02-22 Thread 'Alex Efros' via golang-nuts

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 
"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/ZdcSCsSUeoSe47GW%40powerman.home.arpa.

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

2024-02-22 Thread Jan Mercl

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.

-- 
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/CAA40n-W2%3DBysk7OHi_OqV%3DM3EO_67JMyy5DjhBEpW7Gaa8FeKw%40mail.gmail.com.

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

2024-02-22 Thread 'Carla Pfaff' via golang-nuts

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 
considering "any" is among the most frequently used constraints in writing 
generic code.

On Thursday 22 February 2024 at 09:10:30 UTC+1 Kurtis Rader wrote:

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?

 

-- 
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/c9c9e11b-9bf8-4ffd-b75e-ebb491962d63n%40googlegroups.com.

[go-nuts] assert library with generics?

2024-02-22 Thread Harmen

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 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/ZdcDz2ULDQl02Z3R%40arp.lijzij.de.

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

2024-02-22 Thread Kurtis Rader

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 <
golang-nuts@googlegroups.com> wrote:

> 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 | float64' constraint. These A|B constraints
> represent a more specialized application of generics, aimed at scenarios
> where there is a need to utilize an operator such as "+". However, the most
> universal, adaptable, and reusable form of a generic type or function — one
> that utilizes 'any' — is notably absent.
>
> --
> 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/0447f6d6-6fe9-410f-9d5a-08bb20bba67en%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9TYR0A5cHfe4FSNnoR5xwY8yhfrJ3P2kLnsCo2bpus6g%40mail.gmail.com.

[go-nuts] Unhappy with the official generics tutorial

2024-02-22 Thread 'Carla Pfaff' via golang-nuts

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 | float64' constraint. These A|B constraints 
represent a more specialized application of generics, aimed at scenarios 
where there is a need to utilize an operator such as "+". However, the most 
universal, adaptable, and reusable form of a generic type or function — one 
that utilizes 'any' — is notably absent.

-- 
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/0447f6d6-6fe9-410f-9d5a-08bb20bba67en%40googlegroups.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[go-nuts] assert library with generics?

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

[go-nuts] Unhappy with the official generics tutorial

18 matches

Site Navigation

Mail list logo

Footer information