Revise general explanation on type casting#1354
Revise general explanation on type casting#1354jaehyun1ee wants to merge 2 commits intop4lang:mainfrom
Conversation
Signed-off-by: Jaehyun Lee <[email protected]>
|
At 2025-Jan-13 vlstill agreed to review in detail. No other LDWG members could think of reasons to object based on our discussion, but they should review and add their comments if they wish. |
vlstill
left a comment
There was a problem hiding this comment.
I agree with the new wording. For the sake of readability of this area of the spec I suggest some tweaks to the following text.
p4-16/spec/P4-16-spec.adoc
Outdated
| section <<sec-implicit-casts>> for implicit casts. While this design is arguably | ||
| more onerous for programmers, it has several benefits: |
There was a problem hiding this comment.
I think the last sentence makes little less sense with the forward references. I suggest something like this:
| 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.
There was a problem hiding this comment.
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.
Signed-off-by: Jaehyun Lee <[email protected]>
| By allowing casts only in limited scenarios, this restriction is more | ||
| onerous for programmers, but it also provides several benefits. |
There was a problem hiding this comment.
nitpick: maybe this would read more naturally:
| By allowing casts only in limited scenarios, this restriction is more | |
| onerous for programmers, but it also provides several benefits. | |
| Allowing casts only in limited scenarios is more onerous for | |
| programmers, but it also provides several benefits. |
Following the discussion made at #1351, this PR revises the general explanation on type casting given in section 8.11. Casts* to the following:
Rather than stating "Casts are only permitted on base types and derived types introduced by
typedef,type, andenum." (which is quite inaccurate), it puts forward references to the following subsections. Because:void,error,match_kind, andstring)structandheadercan be casted, e.g., at initialization.