Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise general explanation on type casting #1354

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Revise general explanation on type casting #1354

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions p4-16/spec/P4-16-spec.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3842,9 +3842,10 @@ Additionally, the maximum size of a variable-length bit-string can be determined
=== Casts

P4 provides a limited set of casts between types. A cast is written
`(t) e`, where `t` is a type and `e` is an expression. Casts are only
permitted on base types and derived types introduced by `typedef`, `type`, and `enum`.
While this design is arguably more onerous for programmers, it has several benefits:
`(t) e`, where `t` is a type and `e` is an expression. Casts are only permitted in
cases as defined in section <<sec-explicit-casts>> for explicit casts and
Comment on lines +3845 to +3846
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this sounds a little better?

Suggested change
`(t) e`, where `t` is a type and `e` is an expression. Casts are only permitted in
cases as defined in section <<sec-explicit-casts>> for explicit casts and
`(t) e`, where `t` is a type and `e` is an expression. Casts are only permitted in
cases defined in section <<sec-explicit-casts>> for explicit casts and

section <<sec-implicit-casts>> for implicit casts. While this design is arguably
more onerous for programmers, it has several benefits:
Comment on lines +3847 to +3848
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the last sentence makes little less sense with the forward references. I suggest something like this:

Suggested change
section <<sec-implicit-casts>> for implicit casts. While this design is arguably
more onerous for programmers, it has several benefits:
section <<sec-implicit-casts>> for implicit casts. Main goals of this design are:

and possibly add

  • It limits implicit casts to the bare minimum.


* It makes user intent unambiguous.
* It makes the costs associated with converting numeric values
Expand All @@ -3853,6 +3854,7 @@ While this design is arguably more onerous for programmers, it has several benef
* It reduces the number of cases that have to be considered in the P4
specification. Some targets may not support all casts.
Comment on lines 3854 to 3855
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say the last one should be separate. and probably not a bulletpoint.

Suggested change
* It reduces the number of cases that have to be considered in the P4
specification. Some targets may not support all casts.
* It reduces the number of cases that have to be considered in the P4
specification.
Note: some targets may not support all casts.


[#sec-explicit-casts]
==== Explicit casts

The following casts are legal in P4:
Expand Down