Repository navigation
[SIMD] Inconsistent toString. #63847
Description
Consider:
import 'dart:typed_data';
void main() {
print('Float32x4 simple : ${Float32x4(1.0, 2.0, 3.0, 4.0)}');
print('Float32x4 special: ${Float32x4(double.nan, double.infinity, -0.0, 3.14159)}');
print('Int32x4 positive: ${Int32x4(1, 2, 3, 4)}');
print('Int32x4 negative: ${Int32x4(-1, -2, 255, -256)}');
print('Float64x2 simple : ${Float64x2(1.5, 2.5)}');
print('Float64x2 special: ${Float64x2(0.1, double.nan)}');
}The toString implementation varies across target platforms:
================= VM (native) =================
Float32x4 simple : [1.000000, 2.000000, 3.000000, 4.000000]
Float32x4 special: [nan, inf, -0.000000, 3.141590]
Int32x4 positive: [00000001, 00000002, 00000003, 00000004]
Int32x4 negative: [ffffffff, fffffffe, 000000ff, ffffff00]
Float64x2 simple : [1.500000, 2.500000]
Float64x2 special: [0.100000, nan]
================= dart2js (node) =================
Float32x4 simple : [1, 2, 3, 4]
Float32x4 special: [NaN, Infinity, -0.0, 3.141590118408203]
Int32x4 positive: [1, 2, 3, 4]
Int32x4 negative: [-1, -2, 255, -256]
Float64x2 simple : [1.5, 2.5]
Float64x2 special: [0.1, NaN]
================= dart2wasm (d8) =================
Float32x4 simple : [1.000000, 2.000000, 3.000000, 4.000000]
Float32x4 special: [NaN, Infinity, -0.000000, 3.141590]
Int32x4 positive: [00000001, 00000002, 00000003, 00000004]
Int32x4 negative: [000000-1, 000000-2, 000000ff, 0000-100]
Float64x2 simple : [1.5, 2.5]
Float64x2 special: [0.1, NaN]
https://dart-review.googlesource.com/c/sdk/+/523460 is trying to add code reuse across most of the target platforms and I'd like to fix this. However, what should the expected behavior here be?
I think we should break toString and not return anything useful there at all so we can have more freedom to e.g. migrate from classes to extension types in the future (or hopefully one day not have a toString method at all dart-lang/language#2756). I don't think that a toString on SIMD types is very useful.
@lrhn thoughts?
Activity
lrhn commentedon Jul 19, 2026
Should be safe enough to fix. In either direction.
Harder to change it to something completely opaque, but possible. If it just printed
Instance of Float32x4(inherited fromObject), that'd be correct. (AndObject.toString()shouldn't contain the type name in production builds, that's unnecessary strings to carry around.)Or we could make all 128-bit SIMD types just return a 32-digit hex number representing their bits. Then the underlying buffer can have that
toString, and all views can be extension types.If we want numbers, I'd probably change the VM to match the others in having a nice looking word for special values with a non-platform-dependent look. But then put
.0on the integer output of Float vectors on web.But this all falls back on using the native
float.toString/double.toStringof the platform.Even the "nice looking"
NaNandInfinityis just how JS'sNumber.toStringworks.VM if definitely using something like
sprintf, which is arguably the right thing to do forfloat32, rather than converting tofloat64first.(They may not agree on all values.)
Having the same output makes it easier to test
toString. But that's also the only thing it should be used for. One should not depend on the output of atoStringthat doesn't specify it's format for anything except looking at while debugging.Every class has a
toString. If it's not documenting its format, then that string is only good for debugging, and not guaranteed to be a stable part of the public API.So don't parse it. If you were intended to parse it, there would probably be a
parsefunction.If there isn't, it's not a serialization format.
(If a
toStringcontains information not available through the public API, then that's a design flaw that should be fixed.)[typed_data] Return 'V128' from SIMD value type toString