On 15.06.26 08: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.
Hey Seifeddine,
I went through the RFC and the implementation tests. A few thoughts...
1) if I did not miss anything the empty string case is not covered.
Would `""` be legal? Any thoughts on providing ways to explicitly
disallow empty strings? I don't think this should be further scope --
because we would need to make sure that we actually have a usable syntax
to disallow empty strings.
2) having strict and non-strict mode in PHP is bad enough, IMO. Seeing
this brought further, and combined with "literal" (literal should be
literal) feels wrong -- a coerced `true` is de facto not a literal 1,
it's a coerced `true`. I understand that you recommend strict and want
to leave it to a vote, but I feel like the "Coercive matching
(alternative)" section should make a stronger point against it, to
discourage a tempting "always been like that" for a new concept.
3) the performance section is thin; solely addressing what Tim brought
up. I am wondering, does introducing this have any implications for
non-literal types? Having a benchmark would be nice. I also agree with
Jorg, that a benchmark comparing the performance with enums (memory +
speed) would be helpful.
4) the last part of the previous point extends to the general usefulness
of the feature. I again have to agree with Jorg: it is not clear what
problem it is trying to solve. Why not enums? It is a trend to get rid
of stringy APIs, and magic strings and ints -- for reasons. But this
feature will encourage bringing them back. With an enum you define it in
one place (easier to refactor), with literal scalar types you repeat it
in multiple places. Do we really want that?
--
Cheers
Nick
