Remove type annotation on ref.is_null

[rossberg]

Before we removed anyref, the ref.is_null instruction had a canonical type:

ref.is_null : [anyref] -> [i32]

One piece of the fallout from removing anyref was that this no longer worked. In order to avoid a dependency on the outcome of the wider discussion opened in WebAssembly/function-references#27, I added a type annotation on the instruction, so that it became

ref.is_null <reftype> : [<reftype>] -> [i32]

(with the understanding that the <reftype> would later be refined to a <heaptype> as per the typed (function) references proposal).

However, given that the discussion on WebAssembly/function-references#27 seems to show a common sentiment to avoid redundant type annotations -- especially considering the many more affected instructions added in something like the GC proposal -- it would be unfortunate if ref.is_null became an outlier. And having adapted all the tests, I can say that it is quite annoying in practice, too (ref.null is tedious enough already).

So I propose removing the annotation and changing the instruction to

ref.is_null : [<reftype>] -> [i32]

such that the a linear validator simply has to check that there is some<reftype> on the stack.

Thoughts?

[eqrion]

ref.is_null <reftype> : [<reftype>] -> [i32]

(with the understanding that the <reftype> would later be refined to a <heaptype> as per the typed (function) references proposal).

Is <heaptype> a value type? My understanding was that it is not. If that's the case, would the refinement be:

ref.is_null <heaptype> : [(ref *null* <heaptype>)] -> [i32]

A nice property of this would be that it would disallow saying ref.is_null (ref externref) which is trivially always true.

[RossTate]

@eqrion, disallowing ref.is_null on non-null types is incompatible with (subsumptive) subtyping. That is, you generally want it to be the case that if an instruction accepts a certain type as input, then it accepts all subtypes of that type as input. Otherwise you get into weird situations where making output types of instructions more precise can break programs.

[rossberg]

@eqrion, yes, that's the refinement, see the func-type proposal for details.

As @RossTate said, you cannot rule out non-nullable types for the null check, since that would not be consistent with subtyping.

[eqrion]

@eqrion, disallowing ref.is_null on non-null types is incompatible with (subsumptive) subtyping. That is, you generally want it to be the case that if an instruction accepts a certain type as input, then it accepts all subtypes of that type as input. Otherwise you get into weird situations where making output types of instructions more precise can break programs.

Ah sorry, I should have been more clear.

I agree that you can't disallow the instruction to operate on subtypes, I was trying to say that it's nice to remove a degree of freedom from the text/binary encoding that can't be meaningfully used correctly.

[titzer]

I would prefer to keep the annotation, because I don't agree it's redundant.

One of the motivations for splitting funcref from externref is that they might have different representations. If they have different representations they might have different null values as well, which means that code generated for ref.is_null might be different.

Removing the annotation would mean the engine would have to use the input type to the operation to determine what code to generate, which is a form of overloading and goes against the general precedent that an engine can determine exactly what code to generate for every bytecode from only its opcode and immediates, and not the types of its operands.

[rossberg]

@titzer, I wish you could have voiced that opinion a tiny bit earlier. ;)

Moving forward, esp with GC and other extensions to reference types, there will potentially be a couple of dozens of instructions in the same category, with an infinite set of possible types, so fairly heavy annotations throughout. For example, should call_ref also have a type annotation? Maintaining such a fully annotated design could induce notable overhead in code size and validation time, for rather little benefit -- you'll need to look at the operand stack anyway, to check the type.

FWIW, I'd still hold the line on overloading. I see what you're saying when comparing to that, but at least technically, this is not overloading, because unlike e.g. addition, the observable behaviour does not depend on the type. It's polymorphism, but in a heap type as opposed to a value type. Whether an implementation chooses to type-specialise is a different question. But precedence for that already exists in some other cases, e.g., how to compile select may depend on what type of operand it has.

[titzer]

Just to capture some of the discussion from today, I think it's not such a big deal in this scenario.

I think we need to be careful about removing type annotations too aggressively in the future. In particular, I think we do need to consider it on a case-by-case basis because a missing type annotation can impact ease of code generation and/or introduce some problems in an interpreter. (and yes, I believe an interpreter tier is increasingly important for big modules).

Just off the top of my head for call_ref, an interpreter could benefit from a function type annotation to know how many arguments to pop, without having to inspect the value and get to the function's (dynamic) type. In general, the reliance on types only known from the operand stack can manifest in the interpreter as instead requiring dynamic type information from a value operand. (select was different because the interpreter can cheat with a universal value representation and doesn't need to inspect the true/false values.) So I would use this as a guide going forward: don't unnecessarily introduce a dependency on having dynamic type information attached to values when run on an interpreter.

[RossTate]

When an interpreter parses the wasm module, it will represent the code via some internal data structure. Can't that data structure be updated with whatever type information it needs for execution as the interpreter validates the module?