# Structs

Brendan Eich brendan at mozilla.com
Wed Jun 2 11:14:02 PDT 2010

```On Jun 1, 2010, at 6:15 PM, Waldemar Horwat wrote:

> b = a[i];
> a[i].x += 1;
>
> Now b.x also reflects the new value of a[i].x; i.e. b is an alias,
> not a mutable copy.  The same thing would happen if one had mutated
> b.x.
>
> That leads to a couple plausible meanings of b === a[i]:
>
> 1.  Pointer equality:  True if and only if mutating one's contents
> would mutate the other's.

That is a good point. Since WebGL demands a[i] be stored as packed
machine types in-line in a vector of such structs, this is really
asking whether b aliases a[i]. We could make this work.

> 2.  Recursive value equality:  True if and only if all of their
> constituent elements are ===.

This is what Sam suggested, citing ECMA-334.

>  I hope that you can't have things like aliases themselves as first-
> class values inside structs, as that could create cycles (although
> you could still make === work in that case if you really wanted to).

The only types WebGL wants inside structs are machine scalar types,
ints and floats of several sizes. But if we take a broader view, we
could try to define structs that can contain (typed arrays of) (other)
structs, so long as everything bottomed out in primitive types.

The complexity of object-reference-typed struct members does not seem
worth it.

> Bit-by-bit equality is not desirable in the presence of NaN's and
> signed zeroes.  If we go with choice 2, the struct {x:17, y:NaN}
> should not be === to {x:17, y:NaN}.  Using bit equality, it might or
> might not be ===, which then could be used to discriminate among
> different kinds of NaN's.  There is currently nothing in the
> language with that power and I'd prefer to keep it that way.

Ok.

/be

```