This definitely seems very messed up.

Here's my attempt at doing better with dealing with it, but it's still not great.

https://gopherjs.github.io/playground/#/k4XCYLcu0T

I made foo not embedded in t, compared foo.Objects instead of foos, and used pointer to &t.

This is why we have a proposal like #633 to clean up how these structs behave. /cc @myitcv

Thanks. Comparing foo.Objects (e.g. t1.foo.Object) instead of foos was key. I hadn't thought of that.

Thanks @theclapp

Can't look in detail right now, so this is a bit of a drive-by comment.

Firstly I agree @shurcooL your correction to t1 := &t{... is important here. This catch adds weight to @flimzy's comment from last week

Looking at the transpiled code:

var t1 *t
_ = t1 == t1

results in:

var $ptr, t1;
t1 = ptrType.nil;
$unused(t1 === t1);

Whereas:

var t1 *t
_ = t1.foo == t1.foo

results in:

var $ptr, t1;
t1 = ptrType.nil;
$unused($internalize(t1.Object.foo, ptrType$1) === $internalize(t1.Object.foo, ptrType$1));

Referring to what I think is the relevant code the case uncovered by @theclapp arises because selector expressions that result in a field value (t1.foo is such an expression) unconditionally $internalize.

So immediately there is a discrepancy in the transpiled code between t1 == t1 and t1.foo == t1.foo, despite them both expressions involved being pointers to *js.Object-struct type values.

At which point I'd be tempted to put this in the bucket of #617. But given botht and foo are *js.Object-special types it inevitably spills over into #633 (as you say @shurcooL).

Either way, we need to work out what we should be doing here (my knee-jerk reaction is that we shouldn't be $internalize-ing any value of type pointer to *js.Object-special struct value, but that's with very little dedicated thought!)

Just to be clear, the comparison is irrelevant here; it boils down to the transpilation of the operands of the binary expression that matters... and this is what's going wrong

As near as I can tell this is still a problem, even if you fix the part where I used t{} instead of &t{}.

Playground link

Based on superficial observation only, this may be related to #843