* Kurtis Rader <kra...@skepticism.us> [240227 03:10]:
> On Mon, Feb 26, 2024 at 11:52 PM tapi...@gmail.com <tapir....@gmail.com>
> wrote:
>
> > On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote:
> >
> > On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com <tapi...@gmail.com>
> > wrote:
> >
> > > From common sense, this is an obvious bug. But the spec is indeed not
> > clear enough.
> > > It doesn't state whether or not comparisons of pointers to two distinct
> > zero-size variables should be consistent in a run session.
> > > Though, from common sense, it should.
> >
> > "Pointers to distinct zero-size variables may or may not be equal."
> >
> > The outcome is specified to be not predictable. Expecting consistency
> > means the outcome should be, or eventually become, predictable. That's
> > the opposite of what the specs say.
> >
> >
> > Then I would argue that the spec never guarantee (x != y) == ! (x == y).
> > for values of any types (including non-zero-size types). :D
> >
>
> The spec is reasonably clear that guarantee does apply to pointers to
> non-zero size variables (e.g., non-empty structs). The issue in this
> discussion thread is limited to the handling of pointers to zero size
> variables.
I interpreted this thread as being about the inconsistency between the
way pointers to zero-size variables were compared vs. non-zero-size
variables. His comment looks perfectly on-topic to me.
> Precisely because of optimizations the compiler may, or may not,
> perform regarding the value of such pointers. I would prefer a stronger
> guarantee regarding pointers to zero size variables, and it looks like a
> lot of Go users agree with you and me, but that doesn't mean the current
> behavior is ipso facto broken or useless. Pointers to zero size variables
> (e.g., empty structs) are a special-case that the Go designers decided to
> leave ambiguous for now.
I have to agree with tapir. 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. 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? And especially
if the result is different depending on whether or not code outside this
function has called &z for z passed as an argument?
https://gotipplay.golang.org/p/ymhsDmJWv8l
If we can at least agree that this ambiguity is no longer desirable,
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.
2. Pointers to distinct zero-size variables are not equal:
This is consistent with the non-zero-size definition, but the
implementation would likely require distinct virtual addresses for
distinct variables. Whether this would require committed memory
corresponding to those virtual addresses is unclear to me.
Definition 1 removes the distinction between empty struct values and
empty struct instances, and the only way for the programmer to get that
distinction back is by using a non-empty struct.
On the other hand, definition 2 preserves the distinction. If a
programmer wants to have instances compare as equal, it is often very
easy to use instances of the empty type rather than instances of a
pointer to the empty type. Implement the methods on the type with value
receivers rather than pointer receivers.
...Marvin
--
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/Zd41i3rHLskqBuef%40basil.wdw.
