Type arguments for generics may be omitted, to be inferred during type checking. Yet, there are also cases where it is unclear what the inferred type argument should be:
header H { bit<8> a; }
struct Headers { H h; }
control c() {
apply {
bit<8> x = 0;
bit<8> y = 0;
y = (x < 4 ? 8w2 : 8w1)[7:0] | 8w8;
}
}
control e<T>();
package top<T>(e<T> e);
top<_>(c()) main;In the above program, c() implements control e<T>(). Type inference should resolve the don't care type (_, which is same as omitting a type variable) in the instantiation top<_>(c()) main;. The specification mentions:
A don't care (underscore, "_") can be used in some circumstances as a type. It should be only used in a position where one could write a bound type variable.
But from the given P4 program, it is unclear what _ actually stands for in the program. In fact, _ suffices to be any legal type. Yet, the current specification is not clear about what to do in such a case. Should it be disallowed to omit type variables where its inferred type is unclear, or should the spec define a way to assign a type for that _?
Below is a list of programs in the p4c test suite that exhibits such situation:
Related test(s):
Type arguments for generics may be omitted, to be inferred during type checking. Yet, there are also cases where it is unclear what the inferred type argument should be:
In the above program,
c()implementscontrol e<T>(). Type inference should resolve the don't care type (_, which is same as omitting a type variable) in the instantiationtop<_>(c()) main;. The specification mentions:But from the given P4 program, it is unclear what
_actually stands for in the program. In fact,_suffices to be any legal type. Yet, the current specification is not clear about what to do in such a case. Should it be disallowed to omit type variables where its inferred type is unclear, or should the spec define a way to assign a type for that_?Below is a list of programs in the
p4ctest suite that exhibits such situation:Related test(s):