add +: slices

[ChrisDodd]

No description provided.

[ChrisDodd]

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 do it only there.

[jafingerhut]

I think it is worth discussing at the next LDWG meeting, exactly when Madoko -> AsciiDoc conversion happens.

Fortunately, for text paragraphs with little or no markup, it usually makes no difference. That said, the changes are so extensive for Madoko->AsciiDoc that I expect if that change is made before this PR, some small changes may be required in this PR. I think small changes to a PR like this to update it will not be wasted effort.

[vlstill]

Looks good to me, except we should add wording that prohibits negative bit indices.

[jafingerhut]

@ChrisDodd Sorry for the inconvenience, but we have, after several months of planning, transitioned the P4 language specification source from Madoko to AsciiDoc. Thus most or all of your PRs will need to be updated so that they apply to that version. Hopefully this should be fairly straightforward, e.g. by looking at examples of how things like section headings, bullet items, etc. are marked up in the latest version of the file P4-16-spec.adoc

If you have questions on how to change things for AsciiDoc, feel free to ask. Note that creating a new PR with similar changes as this PR might be easier than updating this PR.

[jafingerhut]

LGTM

[jafingerhut]

@vlstill Please take another look to see if you have any further comments or questions, and if not, please approve.

[jafingerhut]

@vlstill Please take another look to see if you have any further comments or questions, and if not, please approve.

The intent is that any compile-time known bit, int, or int type value should be allowed for value L, and any run-time variable value with type bit<W>, since we can guarantee it is non-negative at compile time, but disallow runtime variable values with type int<W>.

[vlstill]

I suggest wording this as for shifts, allowing only int or bit<W>, not int<W> (https://p4.org/wp-content/uploads/2024/10/P4-16-spec-v1.2.5.html#sec-a-note-about-shifts). This also matches what was discussed on the last LDWG. We cannot defer to the shift for the int<W> index as shift does not allow int<W> to avoid probelems with negative values.

[ChrisDodd]

Maybe add a precise definition for "non-negative" somewhere -- either a bit<W> value or a compile time known value that is >= 0. I don't think we need to (or should) specifically disallow int<W> compile-time-known values.

[vlstill]

I think the formulation that is used for RHS of shifts permits that:

[...] the right operand of shifts must be either an expression of type bit<S> or a compile-time known value that is a non-negative integer.

I suggest we use the same.

I think a restriction to operation types is something important enough to have it written in the operation description and not hidden in a definition of non-negativity.

[jafingerhut]

@ChrisDodd Any thoughts on updates to this PR to address this comment?

[ChrisDodd]

I added a line here to clarify that the index must be a bit<W> type if it is not compile-time-known, in order to be compatible with shift.

[jafingerhut]

I see. @vlstill Any additional comments, or does it look good to you?

[jonathan-dilorenzo]

@vlstill, please take another look or let us know if this is ready to merge so I can merge it. Otherwise, @jonathan-dilorenzo and @vlstill can discuss this in the September LDWG.

[jonathan-dilorenzo]

LGTM. Approving and merging. @vlstill, if you have remaining comments, let's fix them in a follow-up CL.