Can functions return type be based on the type specialization and namelookup

[apinski-cavium]

With the reference compiler I see the following works:

Type func<Type > (inout Type a)
{
  return a;
}

BUT if we change Type to type:

type func<type> (inout type a)
{
  return a;
}

the reference compiler no longer accepts this: t.p4(1):syntax error, unexpected IDENTIFIER, expecting ENUM or HEADER or HEADER_UNION or STRUCT

I don't see anywhere in the specifications that says types need to start with a capital letter (maybe I Missed it). Because even this works:

typedef bit<32> type;
type func<type>(inout type a)
{
  return a;
}

What is the return type there? Is it the specialization or the original defined type?

[apinski-cavium]

So I just checked the reference compiler and noticed the name resolution of the return type is done with the type specialization but that looks a bit odd.

[jafingerhut]

I am a little bit surprised that any of those gives no errors, given that type is some kind of reserved or keyword of the P4_16 language.

[jnfoster]

The parser has some special logic to allow keywords like type to be used as identifiers when there is no ambiguity.

For example: https://github.com/p4lang/p4c/blob/main/frontends/parsers/p4/p4parser.ypp#L447

I'm not surprised there are some bugs and inconsistencies.

[apinski-cavium]

Oh so it looks like type keyword is the issue here, for some reason I thought type was not a keyword when I was writing the example case :). I do have to wonder why the typedef case works though ....

So the following works with the reference compiler after all:

tt func<tt> (inout tt a)
{
  return a;
}

But there is still an issue of describing the name resolution for the return type:

typedef bit<32> tt;
tt func<tt> (inout tt a)
{
  return a;
}
void main()
{
  bit<16> a;
  func(a);
}

The reference compiler assumes it is bit<16> and I would have thought it would have been bit<32>.

Maybe add the following to section 9 under Function declarations to resolve the issue with name lookup: The return type can be an type parameter and will be taken as that rather than doing a name resolution of the scopes.

[apinski-cavium]

Also I see why:

typedef bit type;

is accepted is because the grammer says to use name. name includes some keywords via nonTypeName. So either we need to accept the case that type/apply/key/actions/state/entries can be used in typedef or we change the definition of the grammer of typedef to just be IDENTIFIER | TYPE_IDENTIFIER.

[mihaibudiu]

I am not sure what the problem is. Do you want to file a new issue for typedef? Perhaps you can submit a PR against the spec and/or grammar. Removing some options will be a backwards-incompatible change.

[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.