Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114941
MIME-Version: 1.0
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com>
 <CAFv4g+GA9y62phk1TB8Z9EakpAXwmOa5pGxT1pdBVZwkCNxsVA@mail.gmail.com> <2768d3ca-7c4f-77f3-d9f5-ff09b932fc80@processus.org>
In-Reply-To: <2768d3ca-7c4f-77f3-d9f5-ff09b932fc80@processus.org>
Date: Fri, 18 Jun 2021 10:41:41 +0100
Message-ID: <CAFv4g+GAOMbC5ujOMxh876Z=6+oxT69o3u3_vkiC=NRguQ=cmg@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000317ef805c50722f8"
Subject: Re: [PHP-DEV] Re: [RFC] is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000317ef805c50722f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 18 Jun 2021 at 8:48 am, Pierre <pierre-php@processus.org> wrote:

> Le 18/06/2021 =C3=A0 08:00, Craig Francis a =C3=A9crit :
> > Keep in mind it might also become a dedicated type in the future.
>
> Hello,
>
> If so, why the question should not be about the type name instead ? It
> might raises different concerns and new arguments to this discussion ?
>
> What is this type ? What does it covers ? Can float, int, etc... be
> literals as well ? Are those subtypes of their actual existing related
> type ? What should be the behavior regarding user method typings, etc etc=
 ?
>
> Instead of introducing is_literal() may be directly introducing those
> types could be a good idea as well ?



Hi Pierre,

On Monday we had the discussion about types:

https://externals.io/message/114835#114846

The RFCs Future Scope was updated to note the suggestion from someniatko
and Matthew about how this could be a type in the future (Joe has also
shown an interest); where it was agreed that it should be added later.

The discussions I=E2=80=99ve had about this flag have been to ensure it cov=
ers all
future use cases, including a dedicated type, where the function is an easy
way to expose this flag to libraries today, so they can handle developer
mistakes gracefully (rather than causing type errors), with types needing
to have their own future/separate discussion.

The type will still use this flag, so it will match the same definition in
the RFC - strings defined by the programmer, and we will include integers
after the feedback from Matthew (integers have always been considered, the
only reason they were originally excluded was because I tried to keep the
definition as small as possible, Matthew noted how they would help
adoption, and no one can find a single issue with allowing them).

The RFC also explains why floats and booleans are not included, so wouldn=
=E2=80=99t
be used by the type for the same reason.

While adding a flag is an ideal to work towards, it is more important to
have this simple change first, so it can start improving security
immediately (so libraries don=E2=80=99t need to wait years for all of their
supported versions of PHP to include the type), and it gives libraries full
freedom in how they handle values which don=E2=80=99t have this flag.

Hopefully this and the Future Scope section can also answer your questions.

Craig

--000000000000317ef805c50722f8--