Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114851
MIME-Version: 1.0
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <CABAhh3Hq+AvA_8LXCLbNNHKELZtZJjsD-ZZpCaCyimG261Owig@mail.gmail.com> <CAFv4g+H_U4vuX+sC9m+WYZv_j2zCbAurdW4xDoiKfYV2NiixOQ@mail.gmail.com>
In-Reply-To: <CAFv4g+H_U4vuX+sC9m+WYZv_j2zCbAurdW4xDoiKfYV2NiixOQ@mail.gmail.com>
Date: Mon, 14 Jun 2021 10:26:21 +0300
Message-ID: <CABAhh3GjZCN23e5YZQNspbgU5Vz6AFMUyY7rKGHTy=7_eaGCng@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] is_literal
From: someniatko@gmail.com (someniatko)

> And I agree, there would be value in having a `literal-string` type, espe=
cially 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 a=
ble to use the `literal-string` for many years; whereas they can use `funct=
ion_exists('is_literal')` today, probably to provide their own function tha=
t 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 handl=
e 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 li=
brary 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