Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114942
To: internals@lists.php.net
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>
 <CAFv4g+GAOMbC5ujOMxh876Z=6+oxT69o3u3_vkiC=NRguQ=cmg@mail.gmail.com>
Message-ID: <9969f24f-fc4f-b1a8-f4af-7610ebb45e2b@processus.org>
Date: Fri, 18 Jun 2021 12:05:14 +0200
MIME-Version: 1.0
In-Reply-To: <CAFv4g+GAOMbC5ujOMxh876Z=6+oxT69o3u3_vkiC=NRguQ=cmg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] Re: [RFC] is_literal
From: pierre-php@processus.org (Pierre)

Le 18/06/2021 à 11:41, Craig Francis a écrit :
> 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.
Thanks for pointing out this discussion, I must have missed it.
> The discussions I’ve had about this flag have been to ensure it covers 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).

Makes sense.

In many cases, I didn't want to bypass/override the RFC to something 
else, but just point out that the discussion about future types names 
could give hint about the function name itself.

Regards,

--

Pierre