toString() Test is more strict than spec for Float32x4.

[nmostafa]

Currently, we verify correctness by strict string comparison, causing failures due to subtle difference in formatting or precision (e.g. "SIMD.Float32x4(1.0, 2.0, 3.0, 4.0)" !== "SIMD.Float32x4(1, 2, 3, 4)"). The spec doesn't dictate specific formatting on lane values.

Better to do CheckValue(.., v, eval(v.toString()), assuming NaNs and Infinities are not tested ?

[ljharb]

What would be the purpose of providing the precision? 1.0 and 1 are equivalent in JavaScript, and both stringify as "1".

I would expect the spec to dictate standard JavaScript string representations for numbers. When would that not be desirable?

[nmostafa]

I agree that using Number.prototype.ToString() is the right answer, and after a closer look at the spec, I think that's the intent:

Let elements be CreateArrayFromList(argument.[[SIMDElements]]).
Let t be the string "SIMD", e.g., "Float32x4".
Let e be ArrayJoin(elements, ", ").
Return a new String value computed by concatenating the values "SIMD.", t, "(", e, and ")".

However, [[SIMDElements]] is defined as an ECMAScript List of values, without specifying the type of those values. Should we add Number to the definition ?

[[SIMDElements]], which is a List of values representing the SIMD contents.

[littledan]

Remember that they may be Booleans. It's true that the spec is unclear; I was imagining that the semantics would be like +, which would call Number.prototype.toString() on Numbers and Boolean.prototype.toString() on Booleans. How does that sound? Spec pull requests are welcome.

[ljharb]

Simply calling the abstract operation ToString on each value should do it, no?

[nmostafa]

Yes. I think just adding a note under [[SIMDElements]] definition indicating that values are either Number or Booleans depending on the SIMDTypeDescriptor should be enough. I will submit a PR.