--
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/d93760c9-61a7-4a3c-9b5c-d89f023d2253n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqrq21ymUJ00ni_JV%3Dkv6itqZg51GoWM5zJNjcGU1BKcuA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqrq21ymUJ00ni_JV%3Dkv6itqZg51GoWM5zJNjcGU1BKcuA%40mail.gmail.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/682fbdcb-546c-4f38-81e8-f9fcfc8f0403n%40googlegroups.com.
On Feb 25, 2024, at 1:02 AM, tapi...@gmail.com <tapi...@gmail.com> wrote:
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/JBVqWYFdtC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e4429119-5c91-44d1-93c4-dc877efdd7b9n%40googlegroups.com.
I learned a lot from this thread, thank you.Intuitively the spec seems to conclude a pointer to an empty struct is a different type of pointer? Normally a pointer wouldn't be able to change values during execution, so we can do things like key maps by pointers.
But if every evaluation of the empty struct pointer can lead to a different outcome, isn't that the same as the address of the pointer arbitrarily changing?
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/96D5EEE6-5E5B-4064-BAA3-AD8B985FE1F0%40gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/JBVqWYFdtC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6fc9b600-6707-414c-b19b-e5e14919c5a5n%40googlegroups.com.
Interesting. That seems to break the comparable spec.>> Pointer types are comparable. Two pointer values are equal if they point to the same variable or if both have value nil. Pointers to distinct zero-size variables may or may not be equal.
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/E875D5D3-FFB2-40BA-B930-A10461A2998E%40gmail.com.
Interesting. That seems to break the comparable spec.>> Pointer types are comparable. Two pointer values are equal if they point to the same variable or if both have value nil. Pointers to distinct zero-size variables may or may not be equal.
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?
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/Zd41i3rHLskqBuef%40basil.wdw.
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/JBVqWYFdtC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHVuxSduyWHG20DjzG1jvE0P06fEqC_FyHdDEWewjOjTg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c7ead734-8ce6-4254-91ac-771b02e527ddn%40googlegroups.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c7b44255-13f1-434d-b569-f592c8e262d4n%40googlegroups.com.
The loop var change *does* break compatibility. And it did so knowingly and - as clearly explained - was an exception.Stop arguing in bad faith.
In the Go 2 transitions document we gave the general rule that language redefinitions like what we just described are not permitted, giving this very proposal as an example of something that violates the general rule. We still believe that that is the right general rule, but we have come to also believe that the for loop variable case is strong enough to motivate a one-time exception to that rule. Loop variables being per-loop instead of per-iteration is the only design decision we know of in Go that makes programs incorrect more often than it makes them correct. Since it is the only such design decision, we do not see any plausible candidates for additional exceptions.
That is two surprises for many people. Several people said the two cases are artificial or "intentionally confusing programs". I'm speechless on such non-serious attitudes. I can't believe that the bar to keep backward-compatibility is down to such a low level.
If backward-compatibility and expectation breaking is not relevant, then okay, it is not relevant.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5227acc2-b8f1-4ce9-9d0c-829930967af4n%40googlegroups.com.