Contents
PHP type declarations explained
Hey, fellow PHP devs. Picture this: it's 2 AM, your screen's the only light in the room, and you're staring at a function that's swallowing an int when it begged for a string. The app chugs along, but something feels off—like a quiet betrayal. We've all been there. PHP's journey from loose, forgiving typing to something sharper started changing everything around PHP 7. That's when type declarations really took hold, giving us tools to catch those sneaky mismatches before they bite.
Type declarations let you specify exactly what a function expects as input, what it spits out, and even what lives in your class properties. No more guessing games. They're optional, sure, but once you lean in, your code reads like a conversation—clear, predictable, human.
Why does this matter? In a world of sprawling PHP apps, legacy code mountains, and teams juggling deadlines, types are your silent guardians. They reduce bugs, speed up onboarding, and make refactoring less terrifying. I've refactored a 50k-line monolith once; without types, it was chaos. With them? A quiet win.
The basics: Where it all started
PHP's always been dynamically typed—variables shapeshift as needed. But since PHP 7, you can declare types for function arguments and return values. Add declare(strict_types=1); at the top of your file, and PHP stops coercing types. Pass a float to an int? Boom, TypeError.
Take this simple driver class:
<?php
declare(strict_types=1);
class Driver {
public string $serial_number;
public function setSerialNumber(string $number): void {
$this->serial_number = $number;
}
public function getSerialNumber(): string {
return $this->serial_number;
}
}
$driver = new Driver();
$driver->setSerialNumber(1234); // TypeError: must be string, int given
Without strict_types, PHP might coerce 1234 to "1234". With it? Hard stop. That's the power—explicit over implicit.
Supported scalar types? int, float, string, bool. Then arrays, objects, callables, iterables. Class names work too: function f(MyClass $c) {}. Only resource is off-limits.
Have you ever chased a bug where "1" + 1 became 2? Types kill that noise.
Evolution across PHP versions
PHP didn't stop at basics. Each release layered on more.
- PHP 7.1:
voidfor no-return functions,?Typefor nullables.function getItem(): ?string { return $_GET['item'] ?? null; } - PHP 7.4: Typed properties!
public string $foo = 'foo';No more untyped class vars inviting madness. - PHP 8.0: Union types (
int|float),mixed(anything goes, but documented),staticreturns, standalonenull|false. - PHP 8.1: Intersection types (
Foo&Bar),neverfor exit/throw funcs. - PHP 8.2: DNF types, literal
true. - PHP 8.3: Typed class constants.
It's like PHP woke up, looked at TypeScript or Rust, and said, "Hold my coffee." Union types shine: function processData(int|float|string $data): void {}. No more docblocks screaming alternatives.
mixed? It's object|array|string|int|float|bool|null—perfect for legacy parsers, but use sparingly. never? For function fail(): never { throw new Exception(); }. Clean.
Question for you: When's the last time you upgraded PHP just for types? Worth it every time.
Strict vs. coercive: The real-world trap
Here's where it gets personal. PHP defaults to coercion for backward compat. sum(int $a, int $b) with sum(1.5, 2.5)? Becomes sum(1, 2) = 3. Handy for old code, disastrous for new.
<?php // No strict_types
function sum(int $a, int $b): int {
return $a + $b;
}
var_dump(sum(1.5, 2.5)); // int(3)
Add declare(strict_types=1);? TypeError. But careful—strict_types is file-level. Call from a non-strict file? Coercion wins.
I learned this the hard way on a client project. Deployed strict types in one module; integrations broke silently. Now? Team rule: strict everywhere, or document why not.
Advanced tricks: Unions, intersections, and beyond
Unions changed my game. Before PHP 8, nullable ?string was union lite. Now? string|int|array|null. Properties too: public int|float $price;.
Intersections? Rare, but gold for interfaces: Logger&Storable $handler. Value must satisfy both.
static return: public static function create(): static { return new static(); }. Perfect for factories.
And never: Imagine validation:
function validateUser(string $email, string $pass): never {
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
throw new InvalidArgumentException('Bad email');
}
// Loops forever or exits, never returns
}
Typed constants in 8.3: public const string API_KEY = 'xyz';. No more stringy ints.
Practical patterns for PHP teams
Let's get hands-on. You're building an e-commerce API. Types everywhere:
<?php
declare(strict_types=1);
interface Product {
public function getPrice(): int|float;
}
class Cart {
/** @var array<Product> */
private array $items = [];
public function add(Product $product): void {
$this->items[] = $product;
}
public function total(): int|float {
return array_reduce($this->items, fn($sum, Product $p) => $sum + $p->getPrice(), 0);
}
}
See? Self-documenting. IDEs light up—autocompletion, refactoring, static analysis with Psalm or PHPStan.
For APIs, union returns: function apiResponse(bool $success, string|array $data): array { return ['success' => $success, 'data' => $data]; }.
Legacy migration tip: Start with properties (7.4+), add args/returns gradually. Tools like Rector automate.
Common pitfalls?
- Forgetting
strict_typescascades. - Overusing
mixed—leads to any-typed hell. - Inheritance: Child methods can widen types (covariance), but strict incoming.
I've seen teams enforce via Psalm level 8. Feels strict, catches 90% bugs pre-deploy.
Why types feel like home now
Types aren't just syntax. They're trust. In a solo late-night debug, or handing code to a junior—they whisper, "This works." PHP's type system evolved from afterthought to powerhouse, mirroring our growing demands.
Remember that 2 AM glow? Next time, types will have your back. Cleaner code, fewer fires, more time for what matters—building things that last.
And in the quiet after the commit, there's a subtle peace knowing your PHP speaks truth.