> And I agree, there would be value in having a `literal-string` type,
> especially when working with IDE's and Static Analysers; but it brings a
> couple of issues that the is_literal() function solves:
Yeah, those are valid arguments why we should have a dedicated
`is_literal()` function, and in fact we could have both the type and
the function at the same time, the same as we have `string` type and
`is_string()` function. My worry is, if type is not added in the
present RFC, adding it later may look as "too low value" and probably
will have a lower chance of being accepted.
> 1) Libraries need to support older versions of PHP, so they wouldn't be able
> to use the `literal-string` for many years; whereas they can use
> `function_exists('is_literal')` today, probably to provide their own function
> that simply returns true on pre PHP 8.1.
If the type is added in say 8.2, they wouldn't be able to use it even
longer. Of course this can be re-modelled using a value object which
performs the is_literal() check in the constructor, however I think a
native PHP type would be better, for example in the case of variance
checks (being a subtype of "string").
> 2) The is_literal() function gives the libraries a choice on how to handle
> the situation. At the moment they just receive a string of unknown origin, so
> they can trigger a warning, while also supporting legacy projects who want to
> switch off the warnings. And some developers might want to use a library that
> has an option that can raise exceptions (so they can be certain there are no
> issues).
If we have both the fn and the type, libraries would still have that
choice, either enforce it solidly and throw TypeError (PHP 8.1), or
polyfill the `is_literal()` function to always return `true` and be
able to both take advantage of PHP 8.1 and work on the earlier
versions.
I hope these points will be really considered, and PHP's type system
will evolve into more robust and strong one. (offtopic: hoping we will
have typed vector and dict types someday too)
> Craig
Regards,
someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
