Re: [RFC] [Discussion] Literal Scalar Types
| From: | Seifeddine Gmati | Date: | Wed, 17 Jun 2026 04:59:51 +0000 |
| Subject: | Re: [RFC] [Discussion] Literal Scalar Types | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131341@lists.php.net to get a copy of this message | ||
On Mon, 15 Jun 2026 at 02:22, Seifeddine Gmati <azjezz@carthage.software> wrote:
>
> Hello Internals,
>
> I'd like to start the discussion on a new RFC adding literal scalar
> types to PHP.
>
> - RFC: https://wiki.php.net/rfc/literal_scalar_types
> - Implementation: https://github.com/php/php-src/pull/22314
>
> Thanks,
> Seifeddine.
Hi all,
Based on the discussion so far, I've updated the Literal Scalar Types
RFC to v0.2:
https://wiki.php.net/rfc/literal_scalar_types
What changed:
- Strict matching is now the proposed default instead of coercion. A
literal type would never coerce, in either typing mode, exactly how
true, false and null already behave: passing 1 where the type is true
is a TypeError even with strict_types disabled. The goal is a single
rule: a type whose identity is one value matches only that value.
- The vote is split into three: a 2/3 vote to add int and string
literals, a separate 2/3 vote to add float literals, and a
simple-majority vote for the matching semantics (strict vs coercive).
- Float support is now its own, optional question. The RFC discusses
the precision issue in full (0.3 won't match 0.1 + 0.2, because 0.1 +
0.2 === 0.3 is already false today) along with the arguments for and
against, mirroring why floats were left out of enum backing types.
- Documented the accepted literal syntax (0x.., 0b.., octal, 4e3,
1_000, and so on) and why named constants, INF and NAN are excluded.
- Added RFC Impact notes for extensions and tooling (parsers, IDEs,
formatters, linters, static analysers), plus a Future Scope section
covering array shapes/tuples and integer range types.
Thanks,
Seifeddine.