====== PHP RFC: Deprecate Fuzzy Scalar Casts and Null Casts ======

  * Version: 1.0
  * Date: 2025-10-28
  * Author: Alexandre Daubois <alexandredaubois@php.net>, Nicolas Grekas <nicolasgrekas@php.net>
  * Status: Under discussion
  * Target Version: PHP 8.6 (deprecation), PHP 9.0 (TypeError)
  * Implementation: TBD

===== Introduction =====

PHP's explicit type casting operators (<php>(int)</php>, <php>(float)</php>, <php>(bool)</php>, <php>(string)</php>, <php>(array)</php>, <php>(object)</php>) have historically been maximally permissive, performing lossy conversions when the input value cannot be fully represented in the target type. This behavior, inherited from early PHP versions, creates **inconsistencies** between explicit casts and function parameter type checking, and can mask bugs by silently converting problematic values.

This RFC addresses two particularly problematic categories of casts:

**1. Fuzzy casts**: conversions where information is lost or transformed in unexpected ways:

<PHP>
<?php
// Partial string conversions - only a portion of the string is used
(int) "123abc";      // Returns 123 (discards "abc")
(float) "12.34foo";  // Returns 12.34 (discards "foo")

// Scalar to object casts - creates arbitrary structure
(object) 42;         // Returns stdClass Object ( [scalar] => 42 )
(object) "hello";    // Returns stdClass Object ( [scalar] => "hello" )
?>
</PHP>

**2. Null casts**: conversions where <php>null</php> is coerced to type-specific default values, masking the absence of data:

<PHP>
<?php
(int) null;          // Returns 0 (null becomes zero)
(string) null;       // Returns "" (null becomes empty string)
(bool) null;         // Returns false (null becomes false)
(array) null;        // Returns [] (null becomes empty array)
(object) null;       // Returns stdClass object (null becomes empty object)
?>
</PHP>

This RFC proposes to **deprecate both fuzzy casts and null casts in PHP 8.6** and **make them throw <php>TypeError</php> in PHP 9.0**, aligning explicit cast behavior with the **existing** validation rules already used for typed function parameters in non-strict mode.

**Important:** This RFC specifically targets **partial string conversions** and **null conversions**. Well-formed numeric strings (e.g., <php>"123"</php>, <php>"12.5"</php>) will continue to work as expected.

===== Background and Motivation =====

==== Historical Context ====

PHP's permissive type casting behavior dates back to PHP 3/4, when the language prioritized ease of use and automatic type juggling. At that time, strict type checking was not a core language feature.

However, since PHP 7.0, the language has evolved to support:
  * Type declarations for function parameters and return values
  * Strict type checking via <php>declare(strict_types=1)</php>
  * Clear <php>TypeError</php> exceptions for invalid type conversions

Despite these improvements, **explicit cast operators have retained their permissive legacy behavior**, creating a significant inconsistency in the language.

==== The Inconsistency Problem ====

Consider these examples:

<PHP>
<?php
// Function parameter type checking - rejects fuzzy conversions
function process(int $value): void {
    var_dump($value);
}

process("123abc");  // TypeError: Cannot convert string to int

// Explicit cast - permissive truncation
$result = (int) "123abc";  // 123 (no error, silently truncates "abc")
?>
</PHP>

<PHP>
<?php
// Function parameter type checking - rejects null
function calculate(int $count): void {
    var_dump($count);
}

calculate(null);  // TypeError: Cannot pass null to non-nullable parameter

// Explicit cast - converts null to 0
$result = (int) null;  // 0 (no error, null becomes zero)
?>
</PHP>

**This is inconsistent and confusing.** Developers expect similar operations to have similar validation rules, but explicit casts are **far more permissive** than function parameter type checking (even in non-strict mode).

==== Security and Correctness Issues ====

Both fuzzy casts and null casts can introduce security vulnerabilities and correctness issues:

**Fuzzy cast issues:**

<PHP>
<?php
// Security risk: silently truncating user input
$limit = (int) $_GET['limit'];  // "100 OR 1=1" becomes 100

// Correctness issue: masking data corruption
$price = (float) $dbRow['price'];  // "19.99corrupted" becomes 19.99

// Logic error: unexpected boolean coercion
$enabled = (bool) $config['enabled'];  // "0 disabled" becomes true (non-empty string)
?>
</PHP>

**Null cast issues:**

<PHP>
<?php
// Ambiguity: is 0 a valid value or was it null?
$age = (int) $row['age'];  // If $row['age'] is null, becomes 0
if ($age === 0) {
    // Is the user a newborn, or was age missing?
}

// Logic error: null becomes falsy
$hasOptedIn = (bool) $userData['newsletter'];  // null becomes false
// User never answered, but we treat it as "no"

// Data loss: null becomes empty string
$middleName = (string) $person['middle_name'];  // null becomes ""
// Cannot distinguish between empty string and missing value
?>
</PHP>

In all these cases, **invalid or missing input is silently accepted** instead of failing fast, making bugs harder to detect and fix.

==== Developer Expectations ====

When developers explicitly cast a value, they typically expect one of two behaviors:

  - **Successful conversion**: The value can be fully interpreted as the target type
  - **Failure**: The value cannot be converted, and an error is raised

The current behavior provides a third, unexpected outcome: **partial conversion with silent data loss**. This violates the principle of least surprise and makes code harder to reason about.

===== Current Behavior =====

PHP's explicit scalar cast operators currently exhibit two problematic behaviors:

==== Fuzzy Conversions ====

Fuzzy conversions parse as much of the input string as possible and discard the rest:

**Integer Casts:**

<PHP>
<?php
(int) "123";       // 123 (valid)
(int) "123abc";    // 123 ⚠️ (fuzzy cast - discards "abc")
(int) "  42  ";    // 42 (whitespace is trimmed)
(int) "abc123";    // 0 (no numeric prefix)
(int) "0x1F";      // 0 (hex not supported in string parsing)
?>
</PHP>

**Float Casts:**

<PHP>
<?php
(float) "12.5";      // 12.5 (valid)
(float) "12.5foo";   // 12.5 ⚠️ (fuzzy cast - discards "foo")
(float) "  3.14  ";  // 3.14 (whitespace is trimmed)
(float) "1e3";       // 1000.0 (scientific notation supported)
(float) "1e3extra";  // 1000.0 ⚠️ (fuzzy cast - discards "extra")
?>
</PHP>

**Boolean Casts:**

Boolean casts are less affected by fuzzy conversion because they rely on truthiness rules rather than parsing:

<PHP>
<?php
(bool) "1";          // true (non-empty string)
(bool) "0";          // false (string "0" is falsy)
(bool) "false";      // true ⚠️ (non-empty string, even if content is "false")
(bool) "";           // false (empty string)
?>
</PHP>

While boolean casts don't perform partial parsing, they still exhibit **counterintuitive behavior** where <php>"0"</php> is falsy but <php>"false"</php> is truthy.

==== Null Conversions ====

All cast operators convert <php>null</php> to type-specific default values:

<PHP>
<?php
// Scalar conversions
(int) null;     // 0 ⚠️ (null becomes zero)
(float) null;   // 0.0 ⚠️ (null becomes zero)
(string) null;  // "" ⚠️ (null becomes empty string)
(bool) null;    // false ⚠️ (null becomes false)

// Compound type conversions
(array) null;   // [] ⚠️ (null becomes empty array)
(object) null;  // object(stdClass)#1 (0) {} ⚠️ (null becomes empty object)
?>
</PHP>

This behavior makes it **impossible to distinguish** between a legitimate value and the absence of a value:

<PHP>
<?php
$age = (int) $row['age'];  // If null, becomes 0
// Problem: 0 could mean "newborn" or "missing data"

$name = (string) $row['name'];  // If null, becomes ""
// Problem: "" could mean "no name" or "missing data"

$tags = (array) $row['tags'];  // If null, becomes []
// Problem: [] could mean "no tags" or "missing data"
?>
</PHP>

==== Comparison with Function Parameters ====

In contrast, typed function parameters in **non-strict mode** reject both malformed strings and null:

<PHP>
<?php
function test(int $i): int { return $i; }

// Fuzzy conversions - rejected
test("123");      // 123 (valid numeric string)
test("123abc");   // TypeError: Cannot convert string to int

// Null conversions - rejected
test(null);       // TypeError: Cannot pass null to non-nullable parameter
?>
</PHP>

This creates a **behavioral inconsistency** between explicit casts and function parameter type checking.

===== Proposal =====

This RFC proposes a **two-phase deprecation** of both fuzzy scalar casts and null casts:

==== Phase 1: PHP 8.6 - Deprecation Notice ====

In PHP 8.6, both fuzzy casts and null casts will emit an <php>E_DEPRECATED</php> notice:

**Fuzzy casts** - when a string value can only be **partially** converted to the target scalar type, or when a scalar is cast to <php>(object)</php>:

**Null casts** - when <php>null</php> is cast to any type:

<PHP>
<?php
// PHP 8.6 behavior

// Valid conversions - no change
(int) "123";       // 123 (no notice)
(int) "  42  ";    // 42 (whitespace is acceptable)
(float) "12.5";    // 12.5 (no notice)
(float) "1e3";     // 1000.0 (scientific notation is acceptable)

// Fuzzy casts - emit E_DEPRECATED
(int) "123abc";    // Deprecated: Partial string conversion from "123abc" to int
                   // Returns: 123

(float) "12.5foo"; // Deprecated: Partial string conversion from "12.5foo" to float
                   // Returns: 12.5

// Scalar to object casts - emit E_DEPRECATED (fuzzy cast)
(object) 42;       // Deprecated: Conversion from int to object is deprecated
                   // Returns: stdClass Object ( [scalar] => 42 )

(object) "hello";  // Deprecated: Conversion from string to object is deprecated
                   // Returns: stdClass Object ( [scalar] => "hello" )

// Null casts - emit E_DEPRECATED
(int) null;        // Deprecated: Implicit conversion from null to int is deprecated
                   // Returns: 0

(string) null;     // Deprecated: Implicit conversion from null to string is deprecated
                   // Returns: ""

(array) null;      // Deprecated: Implicit conversion from null to array is deprecated
                   // Returns: []
?>
</PHP>

The deprecation notice will clearly indicate:
  * For fuzzy casts: The original value, the target type, and the nature of the problematic conversion
  * For null casts: That the conversion from null to the target type is deprecated
  * That these conversions will become errors in PHP 9.0

==== Phase 2: PHP 9.0 - TypeError ====

In PHP 9.0, both fuzzy casts and null casts will throw a <php>TypeError</php> instead of performing conversion:

<PHP>
<?php
// PHP 9.0 behavior

// Valid conversions - no change
(int) "123";       // 123
(float) "12.5";    // 12.5

// Fuzzy casts - throw TypeError
(int) "123abc";    // TypeError: Cannot convert string "123abc" to int: trailing data
(float) "12.5foo"; // TypeError: Cannot convert string "12.5foo" to float: trailing data
(object) 42;       // TypeError: Cannot convert int to object
(object) "hello";  // TypeError: Cannot convert string to object

// Null casts - throw TypeError
(int) null;        // TypeError: Cannot convert null to int
(string) null;     // TypeError: Cannot convert null to string
(bool) null;       // TypeError: Cannot convert null to bool
(array) null;      // TypeError: Cannot convert null to array
(object) null;     // TypeError: Cannot convert null to object
?>
</PHP>

This aligns explicit cast behavior with the validation rules already used for typed function parameters in non-strict mode.

**Note:** These are not new validation rules. Function parameters in non-strict mode have rejected fuzzy conversions and null values since PHP 7.0. This RFC simply applies the same proven, consistent behavior to explicit cast operators.

===== Scope and Affected Cases =====

==== What is Considered a Fuzzy Cast? ====

A fuzzy cast occurs when:

  - **Partial string conversions**: The input is a **string** containing a valid numeric prefix **followed by non-numeric/non-whitespace characters**, and the cast operator uses only the valid prefix and discards the trailing data
  - **Scalar to object casts**: A scalar value (<php>int</php>, <php>float</php>, <php>string</php>, or <php>bool</php>) is cast to <php>(object)</php>, creating a <php>stdClass</php> with an arbitrary <php>scalar</php> property

**Examples of fuzzy casts (affected by this RFC):**

<PHP>
<?php
// Partial string conversions
(int) "123abc";         // ✗ Fuzzy cast
(int) "42.5extra";      // ✗ Fuzzy cast
(float) "12.34foo";     // ✗ Fuzzy cast
(float) "1e3garbage";   // ✗ Fuzzy cast

// Scalar to object casts
(object) 42;            // ✗ Fuzzy cast
(object) 3.14;          // ✗ Fuzzy cast
(object) "hello";       // ✗ Fuzzy cast
(object) true;          // ✗ Fuzzy cast
?>
</PHP>

**Examples of valid casts (NOT affected):**

<PHP>
<?php
(int) "123";            // ✓ Fully numeric string
(int) "  42  ";         // ✓ Whitespace is acceptable (trimmed)
(int) "  42\n";         // ✓ Whitespace/newlines are acceptable
(float) "12.5";         // ✓ Fully numeric string
(float) "1e3";          // ✓ Scientific notation
(float) "  3.14  ";     // ✓ Whitespace is acceptable

// Non-string inputs - not affected (except object casts)
(int) 123.0;            // ✓ Float to int conversion
(int) true;             // ✓ Boolean to int conversion
(float) 42;             // ✓ Int to float conversion

// Array to object - not affected
(object) ['name' => 'John'];  // ✓ Array to object (keys become properties)
?>
</PHP>

==== What About Boolean Casts? ====

Boolean casts do not perform partial string parsing in the same way as numeric casts. They rely on PHP's truthiness rules:

<PHP>
<?php
(bool) "0";       // false (string "0" is falsy)
(bool) "false";   // true (non-empty string)
(bool) "";        // false (empty string)
?>
</PHP>

While this behavior is counterintuitive (e.g., <php>"false"</php> being truthy), it is **not a fuzzy cast** in the sense defined by this RFC. Boolean casts evaluate the entire string value according to truthiness rules rather than parsing a numeric prefix.

**This RFC does not change boolean cast behavior.** However, developers are encouraged to use explicit comparisons for clarity:

<PHP>
<?php
// Instead of this:
$enabled = (bool) $value;

// Prefer explicit comparison:
$enabled = $value !== "" && $value !== "0" && $value !== false && $value !== null;

// Or for boolean strings:
$enabled = filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE);
?>
</PHP>

==== What is Considered a Null Cast? ====

A null cast occurs when:

  - The input value is <php>null</php>
  - Any explicit cast operator is used on it

**Examples of null casts (affected by this RFC):**

<PHP>
<?php
(int) null;         // ✗ Null cast to int
(float) null;       // ✗ Null cast to float
(string) null;      // ✗ Null cast to string
(bool) null;        // ✗ Null cast to bool
(array) null;       // ✗ Null cast to array
(object) null;      // ✗ Null cast to object
?>
</PHP>

**All null casts are deprecated** because they mask the absence of data and create ambiguity.

**Migration strategies for null handling:**

<PHP>
<?php
// Option 1: Use null coalescing operator
$age = $row['age'] ?? 0;  // Explicit default value

// Option 2: Explicit null check
if ($value !== null) {
    $result = (int) $value;
} else {
    // Handle null case explicitly
}

// Option 3: Use nullable types in function signatures
function process(?int $value): void {
    if ($value === null) {
        // Handle null explicitly
    } else {
        // Process non-null value
    }
}
?>
</PHP>

==== Summary Table ====

**Important:** The proposed behavior for explicit casts aligns with the **existing validation rules** used by typed function parameters in **non-strict mode** (without <php>declare(strict_types=1)</php>). This RFC does not introduce new type validation rules—it applies the same well-established rules that have been used for function parameters since PHP 7.0.

^ Input Type ^ Cast ^ Current Behavior ^ PHP 8.6 ^ PHP 9.0 ^
| String (fully numeric) | <php>(int) "123"</php> | 123 | 123 | 123 |
| String (whitespace + numeric) | <php>(int) "  42  "</php> | 42 | 42 | 42 |
| String (fuzzy) | <php>(int) "123abc"</php> | 123 | E_DEPRECATED + 123 | TypeError |
| String (fuzzy) | <php>(float) "12.5foo"</php> | 12.5 | E_DEPRECATED + 12.5 | TypeError |
| String (non-numeric) | <php>(int) "abc"</php> | 0 | 0 | 0 |
| null | <php>(int) null</php> | 0 | E_DEPRECATED + 0 | TypeError |
| null | <php>(string) null</php> | "" | E_DEPRECATED + "" | TypeError |
| null | <php>(bool) null</php> | false | E_DEPRECATED + false | TypeError |
| null | <php>(array) null</php> | [] | E_DEPRECATED + [] | TypeError |
| null | <php>(object) null</php> | empty <php>stdClass</php> | E_DEPRECATED + empty <php>stdClass</php> | TypeError |
| Scalar (fuzzy) | <php>(object) 42</php> | <php>stdClass</php> with <php>scalar</php> property | E_DEPRECATED + <php>stdClass</php> | TypeError |
| Scalar (fuzzy) | <php>(object) "hello"</php> | <php>stdClass</php> with <php>scalar</php> property | E_DEPRECATED + <php>stdClass</php> | TypeError |
| Array | <php>(object) ['a' => 1]</php> | <php>stdClass</php> with properties | <php>stdClass</php> (not affected) | <php>stdClass</php> (not affected) |
| Non-string | <php>(int) 12.5</php> | 12 | 12 (E_DEPRECATED for precision loss) | 12 (may throw in future) |
| Boolean string | <php>(bool) "false"</php> | true | true (not affected) | true (not affected) |

===== Backward Compatibility Impact =====

This RFC introduces **backward incompatible changes** that will affect existing code relying on fuzzy cast or null cast behavior.

==== Potential Impact ====

Code that currently relies on fuzzy casts or null casts will need to be updated. Common patterns that will be affected include:

**Fuzzy cast patterns:**

<PHP>
<?php
// Database/API responses with trailing whitespace or corruption
$age = (int) $row['age'];  // If $row['age'] is "25\0" or "25 years"

// User input with mixed content
$quantity = (int) $_POST['quantity'];  // If input is "10 items"

// Configuration values with units
$timeout = (int) $config['timeout'];  // If config is "30s" or "30 seconds"

// Scalar to object wrapping
$wrapped = (object) $someScalar;  // Creates stdClass with 'scalar' property
?>
</PHP>

**Null cast patterns:**

<PHP>
<?php
// Database columns that may be NULL
$age = (int) $row['age'];  // If $row['age'] is null, becomes 0

// Optional form fields
$middleName = (string) ($_POST['middle_name'] ?? null);  // null becomes ""

// API responses with optional fields
$count = (int) $response['count'];  // If 'count' is null, becomes 0

// Configuration with optional values
$maxRetries = (int) $config['max_retries'];  // null becomes 0
?>
</PHP>

==== Migration Path ====

Developers have several options to migrate away from fuzzy casts and null casts:

**For fuzzy casts:**

**Option 1: Validate before casting**

<PHP>
<?php
// Explicit validation using is_numeric()
if (!is_numeric($value)) {
    throw new ValueError("Invalid numeric value: $value");
}
$result = (int) $value;
?>
</PHP>

**Option 2: Use filter functions**

<PHP>
<?php
// Validate and convert
$result = filter_var($value, FILTER_VALIDATE_INT);
if ($result === false) {
    throw new ValueError("Invalid integer: $value");
}

// Sanitize before converting (explicit intent)
$sanitized = filter_var($value, FILTER_SANITIZE_NUMBER_INT);
$result = (int) $sanitized;
?>
</PHP>

**For null casts:**

**Option 1: Use null coalescing operator**

<PHP>
<?php
// Provide explicit default value
$age = $row['age'] ?? 0;  // 0 is the intended default
$name = $row['name'] ?? '';  // Empty string is the intended default
$tags = $row['tags'] ?? [];  // Empty array is the intended default
?>
</PHP>

**Option 2: Explicit null check**

<PHP>
<?php
if ($value !== null) {
    $result = (int) $value;
} else {
    // Handle null case explicitly
    throw new ValueError("Value cannot be null");
    // Or provide a default:
    // $result = 0;
}
?>
</PHP>

**Option 3: Use nullable types**

<PHP>
<?php
// Accept and preserve null in type system
function process(?int $value): void {
    if ($value === null) {
        // Handle null explicitly
    } else {
        // Process non-null value
    }
}

// Or at variable level
$age = $row['age'];  // Keep as ?int, don't cast
if ($age !== null) {
    // Work with non-null int
}
?>
</PHP>

**For scalar to object casts (fuzzy cast):**

**Option 1: Create a proper object structure**

<PHP>
<?php
// Instead of:
$obj = (object) 42;

// Use:
$obj = new stdClass();
$obj->value = 42;

// Or create a proper class:
class ValueWrapper {
    public function __construct(public mixed $value) {}
}
$obj = new ValueWrapper(42);
?>
</PHP>

**Option 2: Use an array if you need a key-value structure**

<PHP>
<?php
// Instead of:
$obj = (object) "hello";

// Use:
$data = ['value' => 'hello'];
// Or if object is required:
$obj = (object) ['value' => 'hello'];
?>
</PHP>

**Option 3: Question whether object wrapping is necessary**

<PHP>
<?php
// Often, the scalar value can be used directly
// Instead of:
$obj = (object) $count;
processObject($obj);

// Consider:
processValue($count);
?>
</PHP>

==== Detection and Tooling ====

To help developers identify fuzzy casts and null casts in their codebase:

  * **PHP 8.6**: The deprecation notices will appear in error logs, making it easy to find affected code
  * **Static analysis tools**: Tools like PHPStan and Psalm can be updated to detect potential fuzzy casts and null casts
  * **Code review**: Search for cast patterns like <php>(int)</php>, <php>(float)</php>, <php>(string)</php>, <php>(object)</php> applied to variables that may be null or contain malformed data

===== Rationale =====

==== Why TypeError Instead of ValueError? ====

We chose <php>TypeError</php> for consistency with:
  * Function parameter type checking (which throws <php>TypeError</php> for invalid conversions)
  * PHP's general convention that type-related validation failures throw <php>TypeError</php>

==== Why These Specific Cases? ====

This RFC focuses specifically on **fuzzy casts** (including partial string conversions and scalar to object casts) and **null casts** because:

  * These are the cases where explicit casts diverge from function parameter validation in non-strict mode
  * They represent the most problematic cases (silent data loss and ambiguity)
  * They are the most likely to mask bugs and cause subtle errors
  * Function parameters already reject these conversions, providing a proven precedent

**Fuzzy casts** silently discard data or create arbitrary structures:
  * Partial string conversions discard trailing data, making malformed input appear valid
  * Scalar to object casts create objects with an arbitrary <php>scalar</php> property that has no meaningful semantic value

**Null casts** make it impossible to distinguish between legitimate values (0, "", [], false) and missing data (null).

Other cast behaviors (e.g., <php>(int) "abc"</php> returning 0) are not addressed by this RFC because:
  * They are well-documented and widely understood
  * They don't involve data loss (the entire string is "consumed")
  * They don't create ambiguity about data presence
  * Changing them would require broader discussion and different tradeoffs

==== Why Encourage filter_var()? ====

The <php>filter_var()</php> family of functions provides **explicit intent**:

<PHP>
<?php
// Intent: Validate that the value is an integer
$value = filter_var($input, FILTER_VALIDATE_INT);

// Intent: Sanitize by extracting numeric characters, then convert
$value = (int) filter_var($input, FILTER_SANITIZE_NUMBER_INT);
?>
</PHP>

This makes code more **readable**, **maintainable**, and **less error-prone** than relying on implicit fuzzy cast behavior.

===== Examples and Use Cases =====

==== Example 1: Database Column with NULL ====

<PHP>
<?php
// Current behavior - null becomes 0, creating ambiguity
$row = ['age' => null];
$age = (int) $row['age'];  // 0 (is this a newborn or missing data?)

if ($age === 0) {
    echo "Baby!";  // Wrong! This is actually missing data
}

// PHP 8.6 - deprecation notice
$age = (int) $row['age'];
// Deprecated: Implicit conversion from null to int is deprecated

// PHP 9.0 - explicit error
$age = (int) $row['age'];
// TypeError: Cannot convert null to int

// Recommended migration - explicit null handling
$age = $row['age'] ?? throw new RuntimeException("Age is required");
// Or with default:
$age = $row['age'] ?? 0;  // Explicitly choosing 0 as default
?>
</PHP>

==== Example 2: Database Column with Corruption ====

<PHP>
<?php
// Current behavior - silently accepts corrupted data
$row = ['age' => '25corrupted'];
$age = (int) $row['age'];  // 25 (corrupted data silently discarded)

// PHP 8.6 - deprecation notice
$age = (int) $row['age'];
// Deprecated: Partial string conversion from "25corrupted" to int

// PHP 9.0 - explicit error
$age = (int) $row['age'];
// TypeError: Cannot convert string "25corrupted" to int: trailing data

// Recommended migration
$age = filter_var($row['age'], FILTER_VALIDATE_INT);
if ($age === false) {
    throw new RuntimeException("Corrupted age value in database: {$row['age']}");
}
?>
</PHP>

==== Example 3: API Response with Units ====

<PHP>
<?php
// Current behavior - silently strips units
$response = ['timeout' => '30s'];
$timeout = (int) $response['timeout'];  // 30 (loses the "s" unit)

// PHP 9.0 - explicit error
$timeout = (int) $response['timeout'];
// TypeError: Cannot convert string "30s" to int: trailing data

// Recommended migration - parse units explicitly
if (preg_match('/^(\d+)\s*s(?:econds)?$/i', $response['timeout'], $matches)) {
    $timeout = (int) $matches[1];
} else {
    throw new ValueError("Invalid timeout format: {$response['timeout']}");
}
?>
</PHP>

==== Example 4: Configuration with Sanitization ====

<PHP>
<?php
// Current behavior - fuzzy cast extracts number
$config = ['max_retries' => '3 times'];
$maxRetries = (int) $config['max_retries'];  // 3

// PHP 9.0 - explicit error
$maxRetries = (int) $config['max_retries'];
// TypeError: Cannot convert string "3 times" to int: trailing data

// Migration option 1: Sanitize explicitly (shows intent)
$sanitized = filter_var($config['max_retries'], FILTER_SANITIZE_NUMBER_INT);
$maxRetries = (int) $sanitized;  // Explicitly extracting number

// Migration option 2: Fix the configuration source
// (Preferred - configuration should store clean values)
$config = ['max_retries' => 3];  // or "3"
$maxRetries = (int) $config['max_retries'];  // Clean conversion
?>
</PHP>

===== Proposed PHP Version =====

  * **PHP 8.6**: Emit <php>E_DEPRECATED</php> for fuzzy casts and null casts
  * **PHP 9.0**: Throw <php>TypeError</php> for fuzzy casts and null casts

===== Voting Choices =====

These are 2 simple yes/no vote requiring a 2/3 majority.

<doodle title="Accept deprecation of fuzzy scalar casts for PHP 8.6/9.0?" voteType="single" closed="false">
   * Yes
   * No
   * Abstain
</doodle>

<doodle title="Accept deprecation of null cast for PHP 8.6/9.0?" voteType="single" closed="false">
   * Yes
   * No
   * Abstain
</doodle>

Vote will start on [TBD] and end on [TBD].

===== References =====

  * RFC: Null Coercion Consistency: https://wiki.php.net/rfc/null_coercion_consistency
  * PHP Type Juggling Documentation: https://www.php.net/manual/en/language.types.type-juggling.php
  * PHP Type Declarations: https://www.php.net/manual/en/language.types.declarations.php
  * PHP filter_var() Documentation: https://www.php.net/manual/en/function.filter-var.php
  * RFC: Deprecate implicit float to int conversions: https://wiki.php.net/rfc/implicit-float-int-deprecate
  * Discussion thread: [TBD]