Understanding PHP’s Strict Types: Scalar Type Declarations Explained

Overview

The RFC proposes adding four scalar type declarations—int, float, string, and bool—that work like existing PHP type hints. It also recommends using an optional file‑level directive declare(strict_types=1); to enable strict scalar type checking for all function calls and returns within that file.

Scalar Type Declarations

These new types are recognized as type hints without introducing new reserved words. They cannot be used for class, interface, or trait names. Internally they are implemented via the Fast Parameter Parsing API.

strict_types Directive

By default, PHP files operate in weak‑type mode. Setting declare(strict_types=1) switches the file to strict mode, where mismatched types trigger E_RECOVERABLE_ERROR instead of warnings. The directive must be the first statement in the file; otherwise a compile error occurs.

Parameter and Return Type Checking

In strict mode, both parameter and return type checks are enforced. Example:

<?php declare(strict_types=1); function add(float $a, float $b): float { return $a + $b; } add(1, 2); // returns float(3)

In weak mode the same call would silently convert the integers to floats.

Weak‑Type Behavior

Weak type checking follows the pre‑PHP7 behavior, allowing most scalar conversions except for NULL, arrays, and resources, which are not accepted as scalar types.

Examples

Typical function with int parameters:

<?php function add(int $a, int $b): int { return $a + $b; } var_dump(add(1, 2)); // int(3) var_dump(add(1.5, 2.5)); // int(3) in weak mode, fatal error in strict mode

When strict mode is enabled, passing a float to an int‑typed parameter results in a catchable fatal error.

Background and Theory

PHP has supported class/interface type hints since PHP 5.0, array hints since 5.1, and callable hints since 5.4. Earlier attempts to add scalar type hints failed due to incompatibilities with extensions and the mixed expectations of strict versus weak typing.

The proposal adopts a hybrid approach: files default to weak typing, but developers can opt‑in to strict typing per file, allowing gradual adoption without breaking existing code.

Why Support Both Modes?

Many developers favor static typing, while others rely on PHP’s flexible weak typing. Providing both options avoids forcing a single model, preserves backward compatibility, and enables a unified error level (E_RECOVERABLE_ERROR) for both user‑defined and built‑in functions when strict mode is active.

Conclusion

The RFC offers a practical path to introduce scalar type declarations and strict type checking while respecting PHP’s legacy codebase, giving developers fine‑grained control over type safety on a per‑file basis.