Rationale for direction "in" meaning "no modifications allowed within the control/action/function/etc. body"?

[jfingerh]

My first quick guess would be "it makes it trivial for an optimizing compiler to know that it need not make a copy of the value, because it cannot be modified".

There is the workaround that a P4 developer can use to make modifications to a local copy where they declare a local variable and explicitly copy the value of the "in" parameter into that local variable, then modify the local variable. One could argue that this makes the introduction of a local copy explicit as a cost that is visible to the P4 developer.

Is there any other rationale not described above?

One perhaps unintended consequence of direction in behavior in the language is that some architectures like TNA and PSA have used direction inout for some parameters, e.g. the type H struct containing headers, in their deparser controls, NOT because the headers are "passed forward" in the architecture to anywhere else after deparsing is complete, but because those architectures chose that to enable calculating IP checksums and modifying those checksum fields in things like IPv4/UDP/TCP headers within the deparser control.

One could argue that perhaps those architectures should instead use direction in for that struct of headers, and require the P4 developer to make a local copy of any headers they want to modify, and only emit the locally modified copy, not the one in the struct of headers that is an in parameter.

Aside: I know that there was mentioned once or twice the proposal for introducing a new direction that was like in, except that local modifications would be explicitly allowed, but did not cause the copy-out behavior of direction inout. I am not proposing that with this question (but have no objections if people think that is a good idea to introduce such a thing -- it does not seem like a high priority thing to me).

[mihaibudiu]

Yes, I think this is the main reason: to enable the compiler to save a copy without doing a complicated analysis.

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