Chris Dodd

I prefer Linux style (backwards compatible forever, but may require some extra shim work) as opposed to Microsoft (backwards compatible as long as it is conventient). Google style leads to...

Most of the support for this is already in p4c -- last remaining piece is https://github.com/p4lang/p4c/pull/5338

I think it should follow roughly the same rules as overload resolution -- so if the functionDeclaration unambiguously matches one in the extern (ignoring argument names), that should be fine....

Hmm. I think you're probably right that having different argument names should at least be a warning, as it makes calls with named arguments confusing as, depending on context, you...

I'm unclear whether these changes need to be also in the asciidoc version, or if that happens automatically. Or perhaps we should wait until after the switchover to asciidoc and...

Both `error` and `match_kind` declarations should only appear in target arch includes, never in user programs, so these rules should really just be codifying what actual arhcitectures (try to) do.

By normal (C/C++) scoping rules, one would expect `h` in the initializer to refer to the local, not the param, so this is initializing the local with itself (an uninitialized...

> C is referring to B, not A? I thought that C refers to A. Yes, I think C unambiguously refers to B here, not A. More problematic is something...

This would seem to be a typo in the spec -- it should be "in the enclosing scope" or "in the scope in which the extern instance declaration appears"

The grammar (in p4c and the spec) currently does not allow annotations on select cases -- that should probably be fixed. `@likely`/`@unlikely` as annotations seems fine to me. The precise...