Just to be sure, do you agree that both the {lo, hi}-returning API and the 
magic-property API should both be able to achieve equivalent performance on a 
JS engine that has specifically added and optimized these int64 builtins?  I 
think this is true.

Assuming so, the reason to prefer the rather more awkward magic-property API 
would be purely because its polyfill is more efficient.  This is a tough 
choice, but it seems like bending the spec for the polyfill is overly 
conservative in this case.  A lot of the use cases I hear for int64 come from 
crypto and other very specific algorithms which already have implementations in 
JS.  In such cases, it seems like the authors have to write a new version of 
the algorithm using the new builtins anyway so, if performance was important, 
they could just keep around the old version and pick which version to call 
based on whether the new builtins are present.  Or they can just wait until the 
optimization is broadly available before switching.

The other main use case I can think of is large compiled C++ codebases.  
However, in our experience, C++ codebases tend not to heavily use int64 so the 
overhead of the polyfill would be less significant.

Are there any other use cases you have in mind that really demand high polyfill 

API considerations aside, though, I like the idea of bringing fast 64-bit 
arithmetic to JS without waiting for value objects.

es-discuss mailing list

Reply via email to