What is the meaning of statements like "X a = a"?

[ajwalton]

As discussed in the LDWG in September 2025 (p4lang/p4c#5092 (comment)), for a declaration statement that uses a identifier of an outer scope as an initialiser for a new entity of the same name, such as:

bit<1> func(in bit<8> a, in bit<1> t) {
    if (t == 1) {
        bit <8> a = a;
        :
    }
    :
}

Is this valid code, where the a used as an initialiser is that of the function declaration, or is this invalid because they refer to the same entity?

The P4 language specification does not state which scope is used for the evaluation of the initialiser and should be updated.

@jonathan-dilorenzo , @ChrisDodd , @KunJeong , @jaehyun1ee , @rcgoodfellow , @fruffy and @jafingerhut for visibility.

[ChrisDodd]

Per 6.6.1 in the spec, the block statement (the curly braces for the if) is a scope, and that is the closest enclosing scope around this use and declaration of a. The only real question is if this is a use of a before the declaration (in which case, per 6.6.1, it is clearly illegal and should be an error), or if it is merely non-sensical (using a local to initialize itself).

More interesting is something like:

bit<1> func(in bit<8> a, in bit<1> t) {
    if (t == 1) {
        bit <8> b = a;
        bit <8> a = 5;
        :
    }
    :
}

This is clearly a case of the local a being used before its declaration, but I suspect the compiler does not flag it as such, being confused by the parameter a in the enclosing scope.

[ajwalton]

Per 6.6.1 in the spec, the block statement (the curly braces for the if) is a scope, and that is the closest enclosing scope around this use and declaration of a. The only real question is if this is a use of a before the declaration (in which case, per 6.6.1, it is clearly illegal and should be an error), or if it is merely non-sensical (using a local to initialize itself).

More interesting is something like:

bit<1> func(in bit<8> a, in bit<1> t) {
    if (t == 1) {
        bit <8> b = a;
        bit <8> a = 5;
        :
    }
    :
}

This is clearly a case of the local a being used before its declaration, but I suspect the compiler does not flag it as such, being confused by the parameter a in the enclosing scope.

There is a third interpretation of the "bit<8> a = a", which is that the initialiser is evaluated before the declaration target "a" is created and hence uses the "a" from the enclosing scope. I think this is eluded to by your last comment. This was the question we discussed at the September LDWG (or at least part of the discussion). The spec doesn't make it clear when the declaration comes into existence. This would determine whether it's using the out scope or attempting to use the variable before it's initialised (ie. non-sensical).

You example is also a very interesting case, (but not the same as the one that prompted this issue). It would seem reasonable that the declaration of "b" would use the "a" from the enclosing scope as the local one has not been declared. (This is consistent with the lifetime being from declaration to the end of the scope.) However it's very confusing to have "a" referring to two different variables in the same scope.

So, what should the spec say on the context of the evaluation of the initialiser and/or when the declared variable comes into existence?

[ChrisDodd]

The spec never says or implies that a declaration only "comes into existence" at some point and is ignored before then. 6.6.1 is prettty clear about what a "scope" is -- it is the space delimited by {..} in a block or declaration, plus the declaration itself (for things like type parameters). Unlike C/C++, there's no concept of lifetime separate from scope and no concept of the declaration "coming into existence" at some point. IMO there is no need to introduce such complications. There's no need to repeat C mistakes.

[ajwalton]

Ok, that makes sense - I don't think we had that interpretation of 6.6.1 when discussing this issue at the LDWG meeting. (I think that this also addresses a couple of other variants that we were discussing.) So, what this is saying is that any declaration in a scope creates a name that exists in the whole of the scope, but that it can't be used until it's declared. So, a local variable can't have the same name as a parameter (eg. for a function) as a local variable as that name already exists in the same scope.

[jonathan-dilorenzo]

Discussed in November LDWG. There is a fairly general agreement that the first a usage should (by the spec and by user intuition) refer to the parameter. Let's discuss with @ChrisDodd in the next LDWG too.

[ChrisDodd]

I would think it better this remain an error, but am willing to be convinced otherwise. Allowing it would conflict with disallowing p4lang/p4c#5096 (comment)

[rcgoodfellow]

See also

• Disallow duplicate declarations within the same scope #1376

[jafingerhut]

I have created some small test programs in P4_16, C, C++, Rust, and Java to see what scoping rules they use when a variable in an inner scope shadows one in an outer scope. You can find the details here: https://github.com/jafingerhut/p4-guide/tree/master/scope-of-declared-variables

Quick summary of results: Today and for several years p4c on P4_16 programs behaves the same as Rust does for what a reference to a symbol name means in an expression.

C/C++ are the same as P4_16 and Rust, except in a statement like this:

int i = i;

In C/C++, the i on the right-hand side refers to the variable i that is being declared in that same line. Its value is uninitialized (I have not checked the C/C++ language specs, perhaps it is specified in some other way in their spec terminology).

In Rust and P4_16, the i on the right-hand side refers to the last earlier definition of i, e.g. in an outer scope. If there is no such earlier definition of i, you get a compile-time error on the right-hand side occurrence of i that it is undeclared.

P4_16 seems to be in reasonable company here, without any changes in p4c's current implementation. I would ask whether we should consider codifying it that way in the spec explicitly.

[rcgoodfellow]

Going to discuss this in the August LDWG meeting. The idea is to get to a determination on this issues in the context of the shadowing discussions we've been having and move forward from there.