Lists are not actually tuple types

[apinski-cavium]

The spec currently says:

The type of a list expression is a tuple type (Section [#sec-synth-types]).

But this is not true as int is not a valid type for tuples even though int types can show up in a list expression, e.g. {1, 1}. This means list expressions has no type until it is bound to a tuple, struct or header type. I think this section should be written in a similar fashion (or even combined) as the key value expression is done. Which reads

For a structure-valued expression `typeRef` is the name of a `struct`
or `header` type.  The `typeRef` can be omitted if it can be inferred
from context, e.g., when initializing a variable with a `struct` type.

It should should allow tuple there and not just struct and header type.

Note this is superset of https://github.com/p4lang/p4-spec/issues/1061 as I didn't notice the int type issue until now.

[mihaibudiu]

Each expression has a type, and a list expression has a tuple type. I really don't see why we would not allow tuple types to have int fields if they are only used in compile-time known contexts.

[apinski-cavium]

Ok, I think I understand this better. So tuples used to be a synthesized type and then it was added as something the user could specify. But the feature looks incomplete and some parts of the spec were not updated for that change. The list part was one of them where it points to sec-synth-types still when refering to a tuple type.

[apinski-cavium]

So this comes into play when we have an expression like {3} == {4} is that valid or not? And is it valid as a compile time known constant too? Currently p4c accepts it while my front-end rejects it as there is tuple<int> is an invalid type. An example for this could be

@myan[{3} == {4}] typedef int b1;

[jnfoster]

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.