Skip to content

Conversation

@brentwilson-clariio
Copy link

Related to #1722

This PR adds a new documentation file:
WordPress/Docs/PHP/TypeCastsStandard.xml

What it covers

Documents the rule enforced by the WordPress.PHP.TypeCasts sniff:

  • Normalizes legacy float casts ((double), (real)) to (float).

Notes

Other type-cast related rules in the WordPress standard are enforced by separate sniffs:

  • Short form keywords ((int), (bool), (string)): PSR12.Keywords.ShortFormTypeKeywords
  • No spaces inside parentheses: Squiz.WhiteSpace.CastSpacing
  • Exactly one space after the cast: Generic.Formatting.SpaceAfterCast

Copy link
Member

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

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

@brentwilson-clariio Thanks for picking this up! I've just had a quick look and left some feedback for you to consider.

Comment on lines 11 to 18
Note: Other type-cast rules in the WordPress standard
are enforced by different sniffs:
- Short forms like (int), (bool), (string):
PSR12.Keywords.ShortFormTypeKeywords
- No spaces inside parentheses:
Squiz.WhiteSpace.CastSpacing
- Exactly one space after the cast:
Generic.Formatting.SpaceAfterCast
Copy link
Member

Choose a reason for hiding this comment

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

This whole block doesn't belong here. Each sniff functions independently of other sniffs. That also means that the docs should be independent of each other and should just focus on what this sniff does.

Choose a reason for hiding this comment

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

Thanks! I’ve removed the paragraph referencing other sniffs. The docs now only describe what WordPress.PHP.TypeCasts enforces.

<code_comparison>
<code title="Invalid: legacy float casts">
<![CDATA[
<?php
Copy link
Member

Choose a reason for hiding this comment

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

PHP open tag is not needed here. (Same for the "invalid" code sample)

Choose a reason for hiding this comment

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

Removed <?php from all code samples as suggested.

<documentation title="Type Casts">
<standard>
<![CDATA[
This sniff normalizes float type cast keywords.
Copy link
Member

Choose a reason for hiding this comment

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

This sentence seems redundant.

Choose a reason for hiding this comment

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

Reworded the opener to be shorter and clearer. It now states the rules enforced without repeating itself.

@@ -0,0 +1,38 @@
<?xml version="1.0"?>
<documentation title="Type Casts">
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<documentation title="Type Casts">
<?xml version="1.0"?>
<documentation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="https://phpcsstandards.github.io/PHPCSDevTools/phpcsdocs.xsd"
title="Type Casts"
>

Choose a reason for hiding this comment

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

Added the schema header and xsi:noNamespaceSchemaLocation pointing to phpcsdocs.xsd.

Comment on lines 7 to 9
Use (float) instead of legacy synonyms:
- Disallowed: (double), (real)
- Allowed: (float)
Copy link
Member

Choose a reason for hiding this comment

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

This is incorrect/incomplete.

The sniff:

  • Forbids the use of non-standard casts for floats.
  • Forbids the use of the (unset) cast.
  • Discourages the use of the (binary) cast.

Considering the above, I believe the code samples also need work.

Choose a reason for hiding this comment

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

Updated the standard text and the code examples to cover all three behaviors:
• (double)/(real) → error (normalize to (float))
• (unset) → error (removed in PHP 8.0; suggest unset())
• (binary) → warning (discouraged)

</standard>

<code_comparison>
<code title="Invalid: legacy float casts">
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<code title="Invalid: legacy float casts">
<code title="Invalid: Using legacy float casts.">

Choose a reason for hiding this comment

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

Adjusted the code block titles to your suggested wording.

$size = <em>(real)</em> $value;
]]>
</code>
<code title="Valid: normalized float cast">
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<code title="Valid: normalized float cast">
<code title="Valid: Using normalized float casts.">

Choose a reason for hiding this comment

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

Adjusted the code block titles to your suggested wording.

Choose a reason for hiding this comment

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

Updated code block titles to “Valid: Using normalized float casts.” (and similar phrasing for the other examples), as suggested.

]]>
</standard>

<code_comparison>
Copy link
Member

Choose a reason for hiding this comment

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

The code comparison should have "valid" on the left (first code sample), "invalid" on the right (second code sample).

Choose a reason for hiding this comment

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

Thanks for the feedback! I’ve reordered the code examples so that Valid is on the left and Invalid is on the right, as suggested.

Copy link
Collaborator

@rodrigoprimo rodrigoprimo left a comment

Choose a reason for hiding this comment

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

Thanks for this PR, @brentwilson-clariio! I'm genuinely sorry for the delay to respond. There was some miscommunication and I didn't realize the WPCS maintainers were waiting for me to post a review. I will make sure to respond faster going forward.

I checked and confirmed that you addressed the points that Juliette raised. I left a few other remarks for us to discuss. Let me know what you think and if you have any questions.

Thanks again.

<documentation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="https://phpcsstandards.github.io/PHPCSDevTools/phpcsdocs.xsd"
title="Type Casts"
>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
>
>

</code>
<code title="Invalid: Using the (unset) cast.">
<![CDATA[
result = <em>(unset)</em> $value;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
result = <em>(unset)</em> $value;
$result = <em>(unset)</em> $value;

bytes below is also missing a $.

Comment on lines +8 to +12
Enforce normalized and safe type casts.

• Use (float) instead of legacy float casts.
• Do not use the (unset) cast. Use unset().
• Avoid the (binary) cast (discouraged).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
Enforce normalized and safe type casts.
• Use (float) instead of legacy float casts.
• Do not use the (unset) cast. Use unset().
• Avoid the (binary) cast (discouraged).
Enforce normalized and safe type casts.
• Use (float) instead of legacy float casts.
• Do not use the (unset) cast. Use unset().
• Avoid the (binary) cast (discouraged).

</code_comparison>

<code_comparison>
<code title="Valid: Prefer a clear alternative.">
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe "Valid: Using (string) cast instead."? This way the title clearly communicates what is the alternative like the other titles.

That being said, I noticed that the sniff also detects the binary string prefix notation b"string" which is also tokenized as T_BINARY_CAST, but in this case using (string) is not the correct alternative. I believe we should explicitly mention in the documentation that b"string" also trigger the sniff both here with an example and in the standard description above.

In that case, the title could be something like "Valid: (binary) is not used." or "Valid: Use (string) or regular strings."

Another option is to create a separate <code_comparison> block for the binary string. Tipically, sniff documentation uses a single <code_comparison> block per warning/error message that is triggered by the sniff. But in this case it might make sense to have a separate block.

What do you think?

<code_comparison>
<code title="Valid: Prefer a clear alternative.">
<![CDATA[
bytes = (string) $value;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
bytes = (string) $value;
bytes = <em>(string)</em> $value;

>
<standard>
<![CDATA[
Enforce normalized and safe type casts.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm unsure about a few things in this paragraph:

  • Mentioning that the casts that are not recommended are not safe. Are they all really not safe? I can see why using the casts that were removed is not safe, but not all casts discouraged by the sniff were removed.
  • Maybe we could explicitly mention the legacy float casts?
  • I don't think it is necessary to mention in parenthesis that (binary) is discouraged. If we want to mention that maybe we can include it in the main sentence?

Here is a suggestion of a possible alternative for description. Feel free to create your own version.

Type casts must use normalized keywords.

    • Use (float) not (double) or (real).
    • Do not use the (unset) cast. Use unset().
    • Do not use the (binary) cast or b"string" prefix. Use (string) casts or regular string literals instead.

<code_comparison>
<code title="Valid: Use unset().">
<![CDATA[
unset( $value );
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
unset( $value );
<em>unset</em>( $value );

@rodrigoprimo
Copy link
Collaborator

rodrigoprimo commented Oct 24, 2025

I just realized something else. From php.net (https://www.php.net/manual/en/language.types.type-juggling.php):

Caution
The (binary) cast and b prefix exists for forward support. Currently (binary) and (string) are identical, however this may change and should not be relied upon.

Since the manual says that there is no guarantee that (binary) and (string) will continue to be identical, I guess we should not recommend it in the documentation. Instead maybe the documentation should say that using (binary) is not recommended without providing an alternative? That may be the reason the sniff message does not recommend using (string).

@jrfnl
Copy link
Member

jrfnl commented Oct 24, 2025

Since the manual says that there is no guarantee that (binary) and (string) will continue to be identical, I guess we should not recommend it in the documentation. Instead maybe the documentation should say that using (binary) is not recommended without providing an alternative? That may be the reason the sniff message does not recommend using (string).

Just so you know: the (binary) cast is deprecated as of PHP 8.5 and will be removed in PHP 9.0. The suggested replacement is using (string). See: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_non-standard_cast_names

@rodrigoprimo
Copy link
Collaborator

Thanks for your input, @jrfnl. In that case, I think that @brentwilson-clariio can ignore my last comment and the documentation can mention that (string) should be used instead of (binary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants