Nate Foster

Neither @apinski-cavium nor @mbudiu-vmw addresses the key element of Vladimir's proposal -- it changes the semantics of `extract` and `emit`. I need to mull it over, but I actually kind...

> @jnfoster -- I think that my proposal extends the semantics of extract() and emit() by defining how they behave for this particular type. All current behaviors should remain unchanged,...

@vgurevich and @hanw: I might myself have missed something, but my understanding of the @apinski-cavium proposal _is_ compatible with the kinds of implementations you are imaging, where no extra storage...

Sorry, I didn't mean to close this! To add one more comment, I think @hanw's two programs can be implemented the same way. ```p4 header h { pad _; bit...

@vgurevich let me just say that, in my experience, messing with equality is a Really Bad Idea. The ramifications of such a change are going to be extensive. And it's...

> @jnfoster -- emit() means reading from the field, isn't it? And the whole purpose here is to allow emitting headers that contain garbage in the padding, instead of zeroes....

The one possible objection to the @apinski-cavium proposal I can imagine is that the implementation of `emit` might be slightly more expensive -- we need to somehow slot in `0`...

If the type (`pad`) determines the value (`0`), why would a target ever want to allocate storage for that field? I mean, sure, a target is free to do that....

Yep, I understand how deparsing works on targets we all care about. (Hence, this comment https://github.com/p4lang/p4-spec/issues/1121#issuecomment-1210094084). I'll ping you on Teams to chat when it's not 11pm in ET.

Before I go to sleep, I'll say that the semantics where `pad` always has an undetermined value is also fine by me (which is why I endorsed it above). I...