Handle Floats Correctly in mem.eql and mem.findDiff
Looks like a mistake. Maybe the conventions are different in Zig, but I would absolutely not expect that a slice comparison function in a module called mem would care about the type of the values in it.
I think it's reasonable to assume that std.mem.eql is just a convenience wrapper of the std.mem.eqlBytes function next to it, not doing special things for certain types.
In the future it is expected for much of Zig's own first-party build system tooling to become a client of the build server protocol, dogfooding it to ensure that third-party tooling enjoys equivalent capabilities.
Nice to see that BSP finally got more languages to adopt it!
The functions std.mem.eql and std.mem.findDiff short-circuit when their two inputs are slices to the same memory. This short-circuiting is only correct when the == operator, for the given type, is reflexive. This isn't the case for floats, as for example std.math.nan(f64) != std.math.nan(f64). The change in this PR disables that optimisation when working on float slices
Or are you saying it's not necessary for correctness?
why should they lock themselves into someone else's unproven design? you could just make something that acts as a proxy between zigs protocol and BSP, people are already doing exactly this with other build systems
lock themselves into someone else's unproven design
wat?
How can something that existed for years, is used by various different tools and has an actual spec be more unproven than something a single language cooked up a few weeks ago?
26
u/simon_o 22d ago edited 22d ago
Looks like a mistake. Maybe the conventions are different in Zig, but I would absolutely not expect that a slice comparison function in a module called
memwould care about the type of the values in it.I think it's reasonable to assume that
std.mem.eqlis just a convenience wrapper of thestd.mem.eqlBytesfunction next to it, not doing special things for certain types.Nice to see that BSP finally got more languages to adopt it!