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 2 commits into
base: main
Choose a base branch
from
Open

Revise general explanation on type casting #1354

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f9a3ae7
Revise general explanation on type casting
jaehyun1ee Dec 3, 2024
23d59b6
Nit pass on cast explainer
jaehyun1ee Jan 21, 2025
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
jaehyun1ee marked this conversation as resolved.
Show resolved Hide resolved
section <<sec-implicit-casts>> for implicit casts. While this design is arguably
more onerous for programmers, it has several benefits:
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for the suggestion, I revised the sentences as:

Casts in P4 are permitted only under the conditions specified in section sec-explicit-casts for explicit casts and section sec-implicit-casts for implicit casts. By allowing casts only in limited scenarios, this restriction is more onerous for programmers, but it also provides several benefits.

I tried to make it explicit that casts are very limited in P4.


* 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.
jaehyun1ee marked this conversation as resolved.
Show resolved Hide resolved

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

The following casts are legal in P4:
Expand Down