Clarification of SIMD objects vs values

[stoklund]

The spec text talks about SIMD objects and SIMD values, where a SIMD object is an object with an internal [[SIMDData]] slot holding a SIMD value. The section about the SIMD constructor prototype talks about a [[SIMDWrapperData]] slot. I assume that is that same thing?

Consider this code:

x = SIMD.Int32x4(1,2,3,4);
y = Object(x);
typeof y;                // "object"
y.toString();            // "SIMD.Int32x4(1, 2, 3, 4)".
typeof x;                // "int32x4"
x.toString();            // TypeError!

The last line will throw a TypeError because the SIMD.Int32x4.prototype.toString method requires a SIMD object. I wonder if that is intentional?

Compare to the Symbol.prototype.toString method which accepts both a symbol value and an object wrapping a symbol.

Something similar is going on with the valueOf and toLocaleString methods.

[stoklund]

The Number prototype methods also accept both number values and objects.

[littledan]

Looks like you found two spec bugs here--good catch!

SIMDWrapperData was renamed SIMDData, but sounds like I missed one usage.

SIMD generally tries to follow the precedent set by Symbol, so we should be accepting of primitive receivers here and make the second change you suggest.

Interested in writing a PR to fix these?

[stoklund]

Sure, I'll make a PR.