Waldemar Horwat waldemar at
Wed Jun 2 15:50:07 PDT 2010

Brendan Eich wrote:
> So either we lose this refactoring equivalence:
> b = a[i];
> b.x = 42;
> assert(a[i].x === 42);
> This assertion botches with Sam's proposed semantics.
> Or else we lose the other equivalence, if we reify a struct-view-object 
> on element extraction (rvalue):
> a[j] = a[i];
> a[j].x = 42;
> assert(a[i].x === 42);
> This example is just like the one above, but uses a[j] for some valid 
> index j, instead of a b temporary. Note that with objects (reference 
> types), specifically a plain old Array of object instances, the 
> assertion holds. But with the sketchy struct semantics I've been 
> proposing, typed-array-of-struct elements behave like value types when 
> assigned to (lvalues), so this assertion botches .
> Structs can't be fully (mutable) value types without breaking one 
> equivalence. Yet they can't be reference types or we lose the critical 
> in-line allocation and packing that WebGL needs, but this leaves them in 
> limbo, breaking another equivalence.

Aargh, what fun!  This is one of the more fascinating aspects of not having type annotations.

Possibly the most ECMAScripty approach would be to break the first equivalence by making the step that converts lvalues to rvalues convert struct references into copies of structs.  In ES5 terms this would be the GetValue internal call.  Struct references would not be first class any more than lvalues are.


More information about the es-discuss mailing list