Treat named arguments as a dependency on parameter names

Named arguments can make a call with several boolean options easier to read. They also mean the caller depends on the callee's parameter names, not only their positions. Renaming a public parameter can therefore break consumers even when its type stays the same.

Name the decision at the call site

<?php
function label(string $sku, bool $includePrefix = true): string {
    return $includePrefix ? 'SKU: '.$sku : $sku;
}
assert(label(sku: 'AX-1', includePrefix: false) === 'AX-1');

This is clearer than a bare false argument when the option's meaning is not obvious. For a public library, choose stable parameter names and consider them part of compatibility review.

Be careful with dynamic arrays

Unpacking an associative array into a function call can turn string keys into named arguments. That is convenient for a controlled internal map, but risky for arbitrary request data. Unknown keys can fail the call, and accepted keys can expose options the caller should not control.

Validate and map the input explicitly before invoking the operation. Do not use a function signature as a substitute for a request schema or authorization policy.

When upgrading dependencies, tests should exercise the actual named calls you rely on. A test of the return value through a different positional call does not catch a parameter rename. If you maintain a library, mention parameter-name changes in compatibility notes and avoid cosmetic renames of widely used public methods. Named arguments improve readability most when the API is stable and the selected names explain an otherwise ambiguous choice.

Reference

Official documentation. The examples here illustrate the stated boundary; adapt them to your application and test its failure paths.