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

[Harri L]

I’m biased as well. FWIW, this is a subpackage of the error handling 
solution, err2 .

The assertion pkg  
is proven to be a precious tool for many projects. It is unique because it 
can be used both for the test and production code runs. You’ll set, e.g., 
assert.NotEmpty(s) in whatever function you need. It’ll be checked in test 
runs *and* regular main() started runs. And all of this is done 
automatically.

For instance, if a currently tested function A calls a function B that uses 
this assertion package and violates assertion, the test fails in function 
A’s caller. Still, you get the whole location list to the call stack no 
matter how deep the call stack is to the function B. This works even over 
Go module boundaries, but you need help with the error result listing, 
e.g., the Vim plugin.

Naturally, the happy path performance has been necessary, and, e.g., 
assert.That is the same as if condition.
​
Br,
-Harri

On Monday, February 26, 2024 at 12:53:10 PM UTC+2 roger peppe wrote:

> I'm biased because I had a big hand in designing the API, but I get a lot 
> of pleasure from using this package:
>
> https://pkg.go.dev/github.com/go-quicktest/qt
>
> It does a lot more than just "equals" and "not equals" but it's still 
> relatively small and low-dependency.
> And the error messages when it fails are decent too.
>
>   cheers,
> rog.
>
> On Thu, 22 Feb 2024 at 08:20, 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ZdcDz2ULDQl02Z3R%40arp.lijzij.de
>> .
>>
>

-- 
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/15daa57e-9f5e-4594-a4a9-5b4a96b7838cn%40googlegroups.com.

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

[Sam Vilain]

Hey, thanks for raising this important use case.  Do you have any 
specific examples in mind you could point to?


I think the answer should follow easily from what defines a new scope.  
New scopes get their own mini-stack frame created, and in that frame the 
context pointer can be saved like any other virtual register or 'g' 
property.  Of course, you know that an if block has its own scope inside 
it, and variables declared inside the if blocks are not in scope outside 
of that block.


You can create a new scope without an if statement, like this:

   func ScopeTest() {
    var varname = "outer"

    {
        var varname = "inner"
        fmt.Printf("varname = %s\n", varname)
    }
    fmt.Printf("varname = %s\n", varname)
   }

This prints:

   varname = inner
   varname = outer

It should follow that context variables declared in a block like that 
would have their state unwound when exiting the block.


Of course, any change in the way that statements are written brings with 
it change, resistance to change, and so on, so if you feel like this is 
jumping through awkward hoops, of course I can understand that 
position.  I feel it myself when I consider language changes a lot of 
the time.  The way I like to look past that is to make sure is that 
real-world examples don't end up /contrived/. It should be clear what is 
going on when written in the way it needs to be written to function as 
before, and that includes concerns around backwards compatibility.


So back to the initial question: can you give an example of somewhere 
that a unit test uses context in a way that you predict this proposal 
will make problematic?  I'd love to explore it to make sure, to make 
sure the proposal has lots of good examples.


Thanks,
Sam

On 2/21/24 2:34 AM, 'TheDiveO' via golang-nuts wrote:
Forgive me if I missed that, but what if I have multiple context vars, 
because I need to pass different (derived) contexts into different 
functions/receivers? Take unit tests as real-world examples.


On Wednesday, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote:

Alright, well thanks for your input.

I do think these questions can be answered; exploring the use
cases in a proposal format should hopefully show that the impact
of closures would not normally be an issue. Possibly the worst
case is if you had a library to some external service, and at some
low layer you're using a closure, well you might need to refactor
that if you wanted to add cross–service tracing support.  But to
be honest, it's probably better that the state you're depending on
is captured in a struct instead of being scattered about loosely
in a scope as with a closure.  And the common practice in Go is to
return types that satisfy interfaces, not function references that
you blind call.

I think I will submit a proposal, but please don't take that to
imply that I think you're "wrong, or mistaken". Your concerns are
legitimate and the proposal should answer them cleanly.  In the
proposal format, hopefully the "litigation", or more exploration
of possible uses and abuses of the system, along with performance
concerns, can be addressed.  I don't want to be dismissive of
them, I just want to understand them.

I had a brief look on the Golang issues in Github and could not
find any prior proposals along this line using "context" and
"dynamic scope" as search terms, so I'll submit this as a "new"
proposal for now.

Thanks again, and truly—thanks for responding, >100% better than
people who just rolled eyes and marked thread as read.

Cheers,
Sam

On 2/20/24 3:35 PM, Axel Wagner wrote:

If I may quote myself:

> And no matter which choice you make for the language - it means
that if the programmers wanted the other, they'd have to jump
through annoying hoops and get confusing and hard to debug problems.

Having a mechanism to get one or the other semantic doesn't
change the fact that it's easy to choose wrongly by accident, as
long as the effect is implicit. In fact, the mechanism you
propose (AIUI) seems extra confusing: Having a function value
sometimes create a new dynamic scope and sometimes not, is weird
and seems like a recipe for frustration.

But really, convincing me isn't really the point, which is why
I'm not super invested in litigating this (otherwise I might try
to come up with realistic examples, for instance. Or explain
further why I'm still not sure that this can be implemented
efficiently). I'm just re-stating what, in the past, where the
reasons why things like this have been rejected. In order to
predict what I would consider a likely outcome of a proposal like
this.

If you think I am wrong or misunderstanding you, you can always
file a proposal to get a more official response.

On Tue, Feb 20, 2024 at 8:18 PM Sam

[go-nuts] How to have panic messages show in a PowerShell console

[Thom BENTLEY]

Hi All, 

OS: Windows 10
GoLang: go1.6.3 windows/386

I am trying to have a go executable run and show the panics it causes in 
the PowerShell console.  

I think I can use GODEBUG, but all the examples I've seen so far are for 
Linux.
I've set that variable to paniclog=1, but nothing changed.

If I run go env, I don't see GODEBUG listed.
Thanks in advance.

-- 


The information in this email and any attachments are intended solely for 
the recipient(s) to whom it is addressed, and may be confidential and/or 
privileged. Any unauthorized distribution or copying of this transmittal or 
its attachments is prohibited. If you are not a named recipient or have 
received this email in error: (i) you should not read, disclose, or copy 
it, (ii) please notify the sender of your receipt by reply email and delete 
this email and all attachments.

-- 
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/c27faf57-74a0-4299-ac61-140e634f5297n%40googlegroups.com.

Re: [go-nuts] How to have panic messages show in a PowerShell console

['Jim Idle' via golang-nuts]

You should upgrade your Go installation to the latest version and retry. Go 
1.6.3, if that is not a typo is very old.

Jim
On Feb 28 2024, at 11:35 am, Thom BENTLEY  wrote:
> Hi All,
>
> OS: Windows 10
> GoLang: go1.6.3 windows/386
>
> I am trying to have a go executable run and show the panics it causes in the 
> PowerShell console.
> I think I can use GODEBUG, but all the examples I've seen so far are for 
> Linux.
> I've set that variable to paniclog=1, but nothing changed.
>
> If I run go env, I don't see GODEBUG listed.
> Thanks in advance.
>
>
> The information in this email and any attachments are intended solely for the 
> recipient(s) to whom it is addressed, and may be confidential and/or 
> privileged. Any unauthorized distribution or copying of this transmittal or 
> its attachments is prohibited. If you are not a named recipient or have 
> received this email in error: (i) you should not read, disclose, or copy it, 
> (ii) please notify the sender of your receipt by reply email and delete this 
> email and all attachments.
> --
> 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 
> (mailto:golang-nuts+unsubscr...@googlegroups.com).
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/c27faf57-74a0-4299-ac61-140e634f5297n%40googlegroups.com
>  
> (https://groups.google.com/d/msgid/golang-nuts/c27faf57-74a0-4299-ac61-140e634f5297n%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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2FC3FDE4-BCC9-4D29-8C74-361801650A1C%40getmailspring.com.

[go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

[Robert Sawicki]

Hey!

As I was looking through Go docs recently, I've noticed docs for x/pkgsite 
wrongly assume that user's $PATH includes $GOPATH/bin, by using `pkgsite` 
as a way to launch the command right after installing it. 

Golang installation docs only mention adding 
*/usr/local/bin/go* to $PATH, so I believe this may be confusing for new 
users. At least it was to me.

Shouldn't these docs explicitly state that they assume that path is added 
to $PATH, just for clarity's sake? Or maybe adding $GOPATH/bin (or $GOBIN) 
to user's $PATH is a worthy addition to installation docs?

I decided to ask here, since I don't want to create a whole Github issue 
just for something like that. If this gains traction, I'm willing to create 
such an issue. 

-- 
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/53386532-7bd4-421a-9f41-b973dbfa68ean%40googlegroups.com.

RE: [go-nuts] How to have panic messages show in a PowerShell console

['BENTLEY Thom' via golang-nuts]

Thanks Jim.
At the moment, I’m using the 1.6.3 version as specified in the internal 
documentation the project I’m learning.
I would definitely like to upgrade go to a much later version.  Just don’t want 
to do it before I know it works on the specified version.


From: Jim Idle 
Sent: Wednesday, February 28, 2024 4:34 PM
To: BENTLEY Thom 
Cc: golang-nuts 
Subject: Re: [go-nuts] How to have panic messages show in a PowerShell console

You should upgrade your Go installation to the latest version and retry. Go 1. 
6. 3, if that is not a typo is very old. Jim On Feb 28 2024, at 11: 35 am, Thom 
BENTLEY  wrote: Hi All, OS: Windows 10 GoLang: go1. 6. 3 
windows/386I

You should upgrade your Go installation to the latest version and retry. Go 
1.6.3, if that is not a typo is very old.

Jim

On Feb 28 2024, at 11:35 am, Thom BENTLEY 
mailto:tbent...@mdsol.com>> wrote:
Hi All,

OS: Windows 10
GoLang: go1.6.3 windows/386

I am trying to have a go executable run and show the panics it causes in the 
PowerShell console.

I think I can use GODEBUG, but all the examples I've seen so far are for Linux.
I've set that variable to paniclog=1, but nothing changed.

If I run go env, I don't see GODEBUG listed.
Thanks in advance.


The information in this email and any attachments are intended solely for the 
recipient(s) to whom it is addressed, and may be confidential and/or 
privileged. Any unauthorized distribution or copying of this transmittal or its 
attachments is prohibited. If you are not a named recipient or have received 
this email in error: (i) you should not read, disclose, or copy it, (ii) please 
notify the sender of your receipt by reply email and delete this email and all 
attachments.

--
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/c27faf57-74a0-4299-ac61-140e634f5297n%40googlegroups.com.

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

-- 
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/6a2ff0c1239542b18312421a2441c01b%403ds.com.

Re: [go-nuts] How to have panic messages show in a PowerShell console

[Kurtis Rader]

On Wed, Feb 28, 2024 at 4:39 PM 'BENTLEY Thom' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks Jim.
> At the moment, I’m using the 1.6.3 version as specified in the internal
> documentation the project I’m learning.
> I would definitely like to upgrade go to a much later version.  Just don’t
> want to do it before I know it works on the specified version.
>

The Go backward compatibility guarantee makes it almost a certainty the
project you're working on will work fine if you upgrade to the current Go
release. There is always a very tiny chance the project depends on a bug
that has been fixed in a newer release but that is so unlikely that I
wouldn't worry about it. Also, if you upgrade to the current Go release and
have problems (which is unlikely) you can always go back to the old
version. The bottom line is that you are unlikely to get any meaningful
assistance with an ancient Go version.

-- 
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%3DD9UQYMA5yY%2B_dm0qtaXujOoynBq-P97-FbiDXideNaiqQ%40mail.gmail.com.

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

['Axel Wagner' via golang-nuts]

Doesn't the `go install` command explicitly instruct you to add
$GOBIN/$GOPATH/bin to your $PATH? To me, that seems enough - it feels a bit
arduous, to expect this piece of information at any single point on the web
where `go install` is mentioned.

On Thu, Feb 29, 2024 at 1:39 AM Robert Sawicki 
wrote:

> Hey!
>
> As I was looking through Go docs recently, I've noticed docs for x/pkgsite
> wrongly assume that user's $PATH includes $GOPATH/bin, by using `pkgsite`
> as a way to launch the command right after installing it.
>
> Golang installation docs only mention adding
> */usr/local/bin/go* to $PATH, so I believe this may be confusing for new
> users. At least it was to me.
>
> Shouldn't these docs explicitly state that they assume that path is added
> to $PATH, just for clarity's sake? Or maybe adding $GOPATH/bin (or $GOBIN)
> to user's $PATH is a worthy addition to installation docs?
>
> I decided to ask here, since I don't want to create a whole Github issue
> just for something like that. If this gains traction, I'm willing to create
> such an issue.
>
> --
> 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/53386532-7bd4-421a-9f41-b973dbfa68ean%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/CAEkBMfG6Qi5%2BWwAkfH2tx9MVHpLpwe2bQKcFYFbmmJ5thvw6BA%40mail.gmail.com.

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

[tapi...@gmail.com]

On Wednesday, February 28, 2024 at 3:19:37 PM UTC+8 Axel Wagner wrote:

That would break backwards compatibility, though. And it would be a 
re-definition (i.e. existing code would compile, but behave differently at 
runtime) and is hence not allowed even under the Go 2 transition rules.


With Go version specified, nothing can be broken. For example, the loop var 
change in Go 1.22 doesn't break backwards compatibility. (Though this is 
not my opinion, ;D)
 

I'm also not sure you can exclude *all* pointers to zero-sized variables. 
Note that `[0]T` is also zero-sized and you can convert slices (even empty 
ones) into array-pointers. And you can take the address of struct fields.

All of this to solve an honestly pretty small issue. It's a corner, yes. 
But it isn't a particularly sharp corner.

On Wed, Feb 28, 2024 at 8:06 AM 'Brian Candler' via golang-nuts <
golan...@googlegroups.com> wrote:

> let's consider the two possible definitions:
>
> 1. Pointers to distinct zero-size variables are equal: [...]
> 2. Pointers to distinct zero-size variables are not equal:

Another possibility:

3. Equality comparisons between pointers to zero-size variables are 
forbidden at compile time.
3a. If you wrap two such values in interfaces and try to compare them, then 
you get a runtime panic, same as certain cases today 
.

Indeed, what if it were forbidden to take a pointer to a zero-sized 
variable in the first place? There is nothing to point at, after all.

On Wednesday 28 February 2024 at 07:17:24 UTC+7 Brien Colwell wrote:

I think the surprising part is that the comparison result can change for 
the same values because of the assumption that pointers never change. This 
is implied by the spec but easy to miss.

"Pointers to distinct zero-size variables may or may not be equal."
"Pointers to distinct zero-size variables may or may not be equal and the 
results may or may not be repeatable in any context."

Agree once a programmer is aware of the behavior it can be avoided.

Best,
Brien


On Feb 27, 2024, at 3:06 PM, 'Axel Wagner' via golang-nuts <
golan...@googlegroups.com> wrote:

On Tue, Feb 27, 2024 at 8:19 PM Marvin Renich  wrote:

Prior to generics, the type of the
arguments to == were easily known to the programmer, and so it was
obvious when this "undefined" exception would raise its ugly head, and
you just didn't use it for empty struct types.  But now, with generics,
this can only be classified as a glaring BUG in the spec.


There is pretty much a 0% chance that we'd change the spec in this regard, 
at this point. It would mean that variable declarations like 
`[1<<30]struct{}` would have to allocate huge chunks of heap, to ensure 
that different index-expressions can have different addresses. And while 
there shouldn't be any code relying on that not happening for correctness, 
there is definitely code out there relying on it for performance (e.g. 
there is a pattern of adding struct fields like `_ [0]func()` to ensure a 
type is not comparable - such a struct would now change alignment and size).

The optimization that variables of zero size can re-use the same address 
has been in Go since before Go 1. Given this, it is pretty much implied 
that comparison of those pointers will sometimes have weird results - the 
only question is, *which* results are weird. I agree that this is one of 
the weirder cases. But I don't think we can practically define `==` for 
pointers to zero-sized variables.

I'll also point out that for generics specifically, I'm not sure *any* 
action would have a practical effect. If the type argument is not 
statically known, we also can't special-case it to take into account that 
it's a pointer to a zero-sized variable. Note that the triggered 
optimization isn't necessarily "these are pointers to zero-sized variables, 
hence I can do whatever I want" - it's "these are pointers to distinct 
variables, hence I can assume they are unequal". That is a generally useful 
optimization and it would still be applied to generic code.

How can a programmer count on x == y having any meaning at all in code like 
this:

func IsEqual[T comparable](x, y T) bool {
return x == y
}

if the definition of == for empty structs is undefined?


The result is defined for empty structs, just not for *pointers* to empty 
structs.
Note that `==` has other edge-cases as well. In particular, for floating 
point/complex type arguments, `==` is irreflexive (e.g. NaN is unequal to 
itself).
I'm not sure that pointers to zero-sized variables make this significantly 
worse.
 

If we can at least agree that this ambiguity is no longer desirable,


I don't think we can agree on that, sorry.
 

let's consider the two possible definitions:

1. Pointers to distinct zero-size variables are equal:

This allows the compiler to easily optimize virtual address usage, but
is inconsistent with the non-zero-size definition.


Please look at the issue I filed for some discussion of

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

['Axel Wagner' via golang-nuts]

The loop var change *does* break compatibility. And it did so knowingly and
- as clearly explained - was an exception.
Stop arguing in bad faith.

On Thu, Feb 29, 2024 at 7:03 AM tapi...@gmail.com 
wrote:

>
>
> On Wednesday, February 28, 2024 at 3:19:37 PM UTC+8 Axel Wagner wrote:
>
> That would break backwards compatibility, though. And it would be a
> re-definition (i.e. existing code would compile, but behave differently at
> runtime) and is hence not allowed even under the Go 2 transition rules.
>
>
> With Go version specified, nothing can be broken. For example, the loop
> var change in Go 1.22 doesn't break backwards compatibility. (Though this
> is not my opinion, ;D)
>
>
> I'm also not sure you can exclude *all* pointers to zero-sized variables.
> Note that `[0]T` is also zero-sized and you can convert slices (even empty
> ones) into array-pointers. And you can take the address of struct fields.
>
> All of this to solve an honestly pretty small issue. It's a corner, yes.
> But it isn't a particularly sharp corner.
>
> On Wed, Feb 28, 2024 at 8:06 AM 'Brian Candler' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> > let's consider the two possible definitions:
> >
> > 1. Pointers to distinct zero-size variables are equal: [...]
> > 2. Pointers to distinct zero-size variables are not equal:
>
> Another possibility:
>
> 3. Equality comparisons between pointers to zero-size variables are
> forbidden at compile time.
> 3a. If you wrap two such values in interfaces and try to compare them,
> then you get a runtime panic, same as certain cases today
> .
>
> Indeed, what if it were forbidden to take a pointer to a zero-sized
> variable in the first place? There is nothing to point at, after all.
>
> On Wednesday 28 February 2024 at 07:17:24 UTC+7 Brien Colwell wrote:
>
> I think the surprising part is that the comparison result can change for
> the same values because of the assumption that pointers never change. This
> is implied by the spec but easy to miss.
>
> "Pointers to distinct zero-size variables may or may not be equal."
> "Pointers to distinct zero-size variables may or may not be equal and the
> results may or may not be repeatable in any context."
>
> Agree once a programmer is aware of the behavior it can be avoided.
>
> Best,
> Brien
>
>
> On Feb 27, 2024, at 3:06 PM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> On Tue, Feb 27, 2024 at 8:19 PM Marvin Renich  wrote:
>
> Prior to generics, the type of the
> arguments to == were easily known to the programmer, and so it was
> obvious when this "undefined" exception would raise its ugly head, and
> you just didn't use it for empty struct types.  But now, with generics,
> this can only be classified as a glaring BUG in the spec.
>
>
> There is pretty much a 0% chance that we'd change the spec in this regard,
> at this point. It would mean that variable declarations like
> `[1<<30]struct{}` would have to allocate huge chunks of heap, to ensure
> that different index-expressions can have different addresses. And while
> there shouldn't be any code relying on that not happening for correctness,
> there is definitely code out there relying on it for performance (e.g.
> there is a pattern of adding struct fields like `_ [0]func()` to ensure a
> type is not comparable - such a struct would now change alignment and size).
>
> The optimization that variables of zero size can re-use the same address
> has been in Go since before Go 1. Given this, it is pretty much implied
> that comparison of those pointers will sometimes have weird results - the
> only question is, *which* results are weird. I agree that this is one of
> the weirder cases. But I don't think we can practically define `==` for
> pointers to zero-sized variables.
>
> I'll also point out that for generics specifically, I'm not sure *any*
> action would have a practical effect. If the type argument is not
> statically known, we also can't special-case it to take into account that
> it's a pointer to a zero-sized variable. Note that the triggered
> optimization isn't necessarily "these are pointers to zero-sized variables,
> hence I can do whatever I want" - it's "these are pointers to distinct
> variables, hence I can assume they are unequal". That is a generally useful
> optimization and it would still be applied to generic code.
>
> How can a programmer count on x == y having any meaning at all in code
> like this:
>
> func IsEqual[T comparable](x, y T) bool {
> return x == y
> }
>
> if the definition of == for empty structs is undefined?
>
>
> The result is defined for empty structs, just not for *pointers* to empty
> structs.
> Note that `==` has other edge-cases as well. In particular, for floating
> point/complex type arguments, `==` is irreflexive (e.g. NaN is unequal to
> itself).
> I'm not sure that pointers to zero-sized variables make this significantly
> worse.
>
>
> If we can at least agree that this ambi