Het Seifeddine,
On 05.07.26 03:25, Seifeddine Gmati wrote:
> Hi Nick,
>
> Thanks for the feedback.
>
> > 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.
>
> Empty strings are supported; "" is a valid literal string type.
> Regarding non-empty-string, that is a separate concept from literal
> types. However, this RFC provides the building blocks to express it in
> the future, through negated types (e.g., !""). There's also the option
> of doing refinement markers on base types (e.g., string[1..]), which
> IIRC Gina is working on or mentioned it somewhere.
>
> Example ( using literal types, negated types, and type aliases ):
>
> ```php
> type NonEmptyString = ! "";
>
> function getNonEmptyString(): NonEmptyString {
> return 'ok'; // ok
> return ''; // err
> }
> ```
Sounds good, thanks. Would be great if this would be spelled out in the RFC.
> > 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.
>
> The RFC highlights that strict matching is already the established
> behavior for existing value-types in PHP, and is the preferred path.
> true, false, and null never coerce, even in coercive mode. Maintaining
> this for all literal types is the only way to ensure a consistent type
> system where a unit type matches exactly its identity, hence it is the
> preferred option.
I believe we speak past each other here. With you that it should be
strict matching, which you also prefer! I am just asking to make the
"Coercive matching (alternative)" section more explicitly spell out why
it isn't a good choice. As in: literal types would be a new feature for
PHP, why would we apply and carry over lose semantics to something
that's called "literal"? Not sure if I express myself good enough here,
get what I mean? In short: make a stronger point for strict!
> > 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.
>
> This proposal has no performance impact on non-literal type checks.
> Comparing it to enums isn't quite apples-to-apples; enums are objects
> and follow standard object comparison logic, whereas these are scalar
> identity checks.
Maybe a benchmark would make a strong point for your proposal? Maybe
better performance? Likely mess memory usage?
> > 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?
>
> The core goal is to expand the type system to allow for more precise
> descriptions of data. While literal types can be used standalone, they
> are fundamental for future features like array shapes, where keys and
> values often need to be narrowed to specific literals (e.g., a status
> key being exactly 'ok' | 'error'). A richer type system, similar to
> what we see in TypeScript, requires literals as a foundational
> building block.
>
> Example ( using literal types, type aliases, array shapes, and integer
> ranges ):
>
> ```php
> type ActionResponse = ['status' => 'ok' | 'error', 'message' =>
> string, ?'data' => array];
>
> interface Action {
> public function perform(Context $ctx, Request $request): ActionResponse;
> }
>
> type PingActionResponse = ['status' => 'ok', 'message' => 'pong',
> 'data' => ['time' => 0..]];
>
> final readonly class PingAction extends Action {
> public function perform(Context $ctx, Request $request):
> PingActionResponse {
> return ['status' => 'ok', 'message' => 'pong', 'data' => ['time'
> => get_time()]];
> }
> }
> ```
Well, I believe you know my opinion here, and that we have fundamentally
different ones -- which is fine. Before we bake anything more types into
the language we should standardise PHPDoc, make an official spec. We got
so many things wrong over the recent years that it would be the more
sensible approach. And then the question remains, should we even inline
types? Or is PHPDoc just great with some improvements and official
acknowledgement?
Not sure if potential future language features, that might never come,
are a good selling point that make an argument for getting literal types
in now.
RE type aliases specifically... Something like: "we need to inline types
to have them right where they are used, but then we want to have type
aliases to move them away elsewhere right after" does make zero sense to
me. How does both fit in the very same argument?
Some years ago I wrote the following somewhere (a "thing" refers to an
"object"):
> This is one of the reasons I don’t like TypeScript. They put type
> definitions everywhere.
>
> My thinking:
> An email is a thing. By having that thing we can describe it, with a
> type. In real life, something that doesn’t exist, can’t have a type.
>
> So why would we do it differently in programming?
>
> A dedicated file/class for each thing is imho better. Eventually, the
> thing is the type by itself. Because if you need the type, you need
> the thing.
>
> What would be cool, is to have a type standard library so that not
> everyone must write it on their own.
Just TypeScript having all these things doesn't mean that they are good
for PHP. We should not make PHP another TypeScript.
>
> Cheers,
> Seifeddine.
--
Cheers
Nick
