Re: [PHP-DEV] [RFC] [Discussion] Literal Scalar Types

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