Non-extensibility of Typed Arrays

Brendan Eich brendan at
Fri Aug 30 12:31:53 PDT 2013

Thanks for the reply, I'll let SM and V8 peeps speak for themselves 
(they retired my SM number ;-).
> Filip Pizlo <mailto:fpizlo at>
> August 30, 2013 10:41 AM
> On Aug 30, 2013, at 9:28 AM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
>> Hi,
>>> Filip Pizlo <mailto:fpizlo at>
>>> August 28, 2013 11:01 PM
>>> Here's the part that gets me, though: what is the value of 
>>> disallowing named properties on typed arrays?  Who does this help?
>> You've heard about symmetry with struct types (ES6), right? Those do 
>> not want expandos. We could break symmetry but at some cost. Too 
>> small to worry about? Outweighed by benefits?
> It's a fair point.  I don't see where it would break semantics but 
> I'll try to do a thought experiment to see if it makes things 
> confusing or inconvenient to the programmer.  Whether or not I care 
> depends on the answers to the following questions:
> 1) Is the purpose to simplify programming by allowing you to add 
> static typing?

No, we put a stake through that cold heart.

> 2) Are we trying to help JITs?

Yes, I think so (SM retirement makes this easy for me to say ;-). Even 
excluding type inference as done in SpiderMonkey, just using PICs, 
structs over against objects can help JITs avoid boxing values, same as 
typed arrays do compared to Arrays.

Sometimes you want a product of different types, not a vector of 
same-typed elements. Typed arrays were designed so you would alias two 
views, crazypants. Structs put on sanepants. Just making sure the 
use-case has clear motivation here.

If so, then the JIT wins implemented today among multiple engines for 
typed array element loads and stores will almost certainly be wanted for 
struct field traffic too.

> 3) Do we just want a sensible way of mapping to binary data?  (For 
> both DOM and C-to-JS compilers)

Yes, and don't forget the GPU as well ("DOM" doesn't take that in).


More information about the es-discuss mailing list