====== PHP RFC: Nullable and Non-Nullable Cast Operators ====== * Version: 1.0 * Date: 2025-10-?? * Author: Alexandre Daubois , Nicolas Grekas * Status: Draft * Target Version: PHP 8.6 * Implementation: TBD ===== Introduction ===== PHP's type casting operators currently almost always convert values to the target type even if it cannot be represented from the original value. For example null is evaluated in the following way: (int) null evaluates to 0, (string) null evaluates to "", and (bool) null evaluates to false. While this behavior is consistent with PHP's loose typing philosophy, it can mask bugs when null should be treated as a distinct absence of value. The "almost always" caveat is because non-Stringable objects when being cast to string with (string) will throw a TypeError instead of returning an empty string. This RFC proposes two new cast operator variants that provide explicit control over null handling **and stricter validation** than traditional casts: * **Nullable cast** (?type): Allows null to pass through unchanged; non-null values are validated and coerced using weak mode rules * **Non-null cast** (!type): Throws TypeError if the value is null or if it fails weak mode validation; valid non-null values are coerced to the target type Unlike traditional casts that silently truncate malformed values (e.g., (int) "123aze" returns 123), these operators reject invalid input while still allowing safe conversions (e.g., (!int) "123" works, but (!int) "123aze" throws). These operators complement PHP's existing nullable type declarations (?int, ?string, etc.) by providing the same semantics at the cast level, with the added benefit of input validation. ===== Current Behavior ===== Currently, PHP casts coerce null to type-specific default values: This behavior applies regardless of the strict_types declaration: The strict_types directive only affects function parameter and return type checking, not explicit casts. ===== Proposal ===== This RFC introduces two new cast operator variants: ==== Nullable Cast: (?type) ==== The nullable cast allows null to pass through without coercion. If the value is not null, it is coerced to the specified type using **weak mode function parameter coercion** (stricter than traditional casts). null, others -> int (?float) $value // null -> null, others -> float (?string) $value // null -> null, others -> string (?bool) $value // null -> null, others -> bool (?array) $value // null -> null, others -> array ?> ==== Non-Null Cast: (!type) ==== The non-null cast throws a TypeError in two scenarios: * **If the value is null**: Rejected because null is not allowed * **If weak mode validation fails**: Rejected for malformed values (e.g., "123aze" cannot be converted to int) Valid non-null values are coerced to the specified type using **weak mode function parameter coercion** (stricter than traditional casts). TypeError, "123" -> 123, "123aze" -> TypeError (!float) $value // null -> TypeError, "12.5" -> 12.5, "abc" -> TypeError (!string) $value // null -> TypeError, 123 -> "123", non-Stringable object -> TypeError (!bool) $value // null -> TypeError, valid values -> bool (!array) $value // null -> TypeError, valid values -> array ?> ===== Type Coercion Semantics ===== The nullable and non-null cast operators use **weak mode function parameter coercion rules**, not the permissive behavior of traditional explicit casts. ==== Mental Model ==== These operators behave exactly as if passing a value through a typed function parameter **in weak mode** (without strict_types): This means the new operators **always** use weak mode validation rules, even when strict_types=1 is declared (see the "Interaction with strict_types" section for details). **Important:** Weak mode validation can still throw TypeError. The function parameter analogy means both the null handling AND the validation behavior match typed parameters - which means TypeError is thrown for both null (when non-nullable) and invalid values that cannot be coerced. ==== Key Difference from Traditional Casts ==== Traditional casts like (int) are **maximally permissive** and perform lossy conversions: ==== Validation Behavior ==== The new operators validate inputs according to weak mode type juggling rules: This behavior ensures that the new cast operators are **stricter** and **safer** than traditional casts while remaining **more convenient** than manual validation. ===== Syntax and Examples ===== ==== Nullable Cast Examples ==== ==== Non-Null Cast Examples ==== ==== Comparison with Current Behavior ==== The key difference: traditional casts are **maximally permissive** (silent data loss), while the new operators use **weak mode validation** (reject malformed input). ==== Behavior Comparison Table ==== ^ Input Value ^ (int) ^ (!int) ^ (?int) ^ Function param int (weak mode) ^ | "123" | 123 | 123 | 123 | 123 | | "123aze" | 123 ⚠️ | TypeError | TypeError | TypeError | | "abc" | 0 ⚠️ | TypeError | TypeError | TypeError | | null | 0 ⚠️ | TypeError | null | TypeError | | 123 | 123 | 123 | 123 | 123 | ⚠️ = potentially unsafe (silent coercion/data loss) The new operators (!type and ?type) align with function parameter behavior, providing safer and more predictable type coercion. ===== Interaction with strict_types ===== These cast operators **always use weak mode coercion rules**, regardless of the strict_types setting: The behavior is uniform because these operators **always use weak mode coercion rules**, even when strict_types=1 is declared. This differs from function parameters, which **do** respect strict_types: The new operators provide a **middle ground**: stricter than traditional casts (validate input), but more permissive than strict mode (allow valid numeric strings). ==== Comparison with Traditional Casts ==== Traditional casts like (int) are always **maximally permissive** regardless of strict_types: ===== Use Cases ===== ==== 1. Database NULL Handling ==== ==== 2. API Response Processing ==== ==== 3. Form Input Validation ==== ==== 4. Type-Safe Wrapper Functions ==== ==== 5. Reducing Boilerplate ==== ===== Comparison Table ===== ^ Cast Type ^ Syntax ^ null Input ^ Valid String ("123") ^ Malformed String ("123aze") ^ | Current cast | (int) $value | 0 ⚠️ | 123 | 123 ⚠️ (silently truncates) | | Nullable cast | (?int) $value | null | 123 | TypeError (validates input) | | Non-null cast | (!int) $value | TypeError | 123 | TypeError (validates input) | **Key differences:** * **Current casts**: Maximally permissive - never throw, may lose data * **New operators**: Validate input using weak mode rules - reject malformed values while accepting valid conversions ===== Supported Types ===== Both ? and ! operators support all existing cast types: * (?int) / (!int) - Integer cast * (?float) / (!float) - Float cast * (?string) / (!string) - String cast * (?bool) / (!bool) - Boolean cast * (?array) / (!array) - Array cast * (?object) / (!object) - Object cast ===== Backward Incompatible Changes ===== This proposal introduces new syntax and has **no backward compatibility issues**: * The syntax (?type) and (!type) are currently parse errors * No existing code uses these patterns * No changes to existing cast behavior * No impact on strict_types semantics ===== Proposed PHP Version ===== PHP 8.6 ===== Voting Choices ===== This is a simple yes/no vote requiring a 2/3 majority. * Yes * No Vote will start on [TBD] and end on [TBD]. ===== References ===== * PHP Type Declarations: https://www.php.net/manual/en/language.types.declarations.php * RFC: Null Coercion Consistency: https://wiki.php.net/rfc/null_coercion_consistency * RFC: Nullable Types: https://wiki.php.net/rfc/nullable_types * RFC: Safe Casting Functions (declined): https://wiki.php.net/rfc/safe_cast * Discussion thread: [TBD]