Behavior of string.eq for null strings
wingo opened this issue · 3 comments
I assume that string.eq should only compare non-null strings; that if either operand is null, that's a trap. But, we should make it explicit.
I wonder if it would be convenient to have (str.eq "foo" null)
return 0
without trapping? That would match what can easily be expressed in e.g. Java (some_string.equals(null)
or Object.equals(some_string, null)
) or JavaScript("foo" == null
).
On the other hand (str.eq null null)
seems weird, so maybe that's a good reason to just trap when any input is null :-)
Perhaps one observation if the instruction traps. What's often seen in languages are patterns like
if (somestring == null) {
...
}
and
if (somestring == otherstring) {
...
}
In the first case the source-level operation can be statically replaced with a ref.is_null
instruction, while in the latter, I'd expect code like the following to ultimately become inlined in each place to match the source-level expectation that null == null
and non-null != null
(e.g. Java, C#, JS-like, ...):
block (result i32)
local.get $lhs
ref.is_null
if
local.get $rhs
ref.is_null
else
local.get $rhs
ref.is_null
if
i32.const 0
else
local.get $lhs
local.get $rhs
string.eq
end
end
end
So I wonder if adhering to null == null
and non-null != null
would have benefits, also because I have found that aborting a program in an unrecoverable way by means of a dynamically trapping instruction is undesirable most of the time?
Those sound like good arguments to me :)