Re: [RFC] [Discussion] Literal Scalar Types

On Mon, 15 Jun 2026 at 06:23, Andreas Heigl <andreas@heigl.org> wrote: > > > > On 15.06.26 06:53, Ben Ramsey wrote: > > On 6/14/26 20:22, Seifeddine Gmati 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. > > > > > > I think I'm okay with this. David mentioned enums, and I do think enums > > are useful in many places where you want types like this, but there's a > > simplicity in this that I can't deny, and I like it. > > I do like the simplicity of this. > > But - especially for floats and ints - the next level would be to allow > not only > > ``` > public function check(int -1|0|1 $minusOneThroughOne) > ``` > > but also something like > > ``` > public function check(int -1..1 $minusOneThrougOne) > ``` > > which would then also allow > > ``` > public function check (int 1..PHP_INT_MAX $positiveInt) > ``` > > would that also be something to be considered? It seems like a logical > alternate option to not have to add every value literally to the option > list... > > Cheers > > Andreas > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andreas@heigl.org N > 50°22'59.5" E 08°23'58" | > | https://andreas.heigl.org > | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas > | > +---------------------------------------------------------------------+ > | GPG-Key: https://hei.gl/keyandreasheiglorg > | > +---------------------------------------------------------------------+ > Hi Andreas, Thanks! Your first example, -1|0|1, is already exactly what this RFC does: a union of three int literals (you don't even need the int prefix, just function check(-1|0|1 $x): void {}). The second part, ranges like -1..1 or 1..PHP_INT_MAX, is a genuinely different feature. And you're right that it's the logical next step: enumerating every value doesn't scale, and something like 1..PHP_INT_MAX can't be written as a union at all. I'd keep it out of this RFC, though. A range isn't a set of literals, it's a constraint that has to be checked with a bounds predicate ($v >= lo && $v <= hi), and it brings its own design questions: inclusive vs exclusive bounds, open-ended ranges (1.., ..10), what's allowed as a bound (plain constants? expressions like PHP_INT_MAX?), and how coercion behaves at the edges. That's really a refinement-type feature sitting on top of this one. So it's a great follow-up, and a natural one once literals exist, but I think it deserves its own proposal rather than being folded in here. Cheers, Seifeddine