Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120949
MIME-Version: 1.0
References: <4406C50C-18FF-4F20-BA7B-206E86610CCC@sakiot.com>
 <245BD1CC-7D54-4CBE-9640-5C8FF5225617@gmail.com> <DB4DCFB3-54EB-433B-AC1A-C1F923DDEFC3@sakiot.com>
 <5B8A7736-9A2A-47E1-B410-4D734DC75EBE@gmail.com>
In-Reply-To: <5B8A7736-9A2A-47E1-B410-4D734DC75EBE@gmail.com>
Date: Tue, 29 Aug 2023 18:36:06 +0200
Message-ID: <CAJmy8YEp_1+Z=jeQ_V7jg5ZOuQ7At9Pt=HsJfnS+WuuwPSei8A@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Saki Takamachi <saki@sakiot.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Apply strict_types to internal functions
From: divinity76@gmail.com (Hans Henrik Bergan)

maybe we could do a
declare(internal_strict_types=3D1);
on a per-file basis just like the existing userland strict_types?
(name is up for bikeshedding ofc)

On Tue, 29 Aug 2023 at 17:49, Claude Pache <claude.pache@gmail.com> wrote:
>
>
>
> > Le 29 ao=C3=BBt 2023 =C3=A0 15:19, Saki Takamachi <saki@sakiot.com> a =
=C3=A9crit :
> >
> >> Hi,
> >>
> >> The larger issue is that higher-order functions do not inherit the `st=
rict_types` mode from its calling code, and this is not specific to interna=
l functions.
> >>
> >> If you intend to change that for internal functions (with proper depre=
cation period, of course), you might consider making such a behaviour also =
possible for userland functions (probably using some opt-in); so that futur=
e higher-order internal functions do not become impossible to polyfill.
> >>
> >> =E2=80=94Claude
> >
> > Hi, thank you for confirming.
> >
> > If you simply put the problem you pointed out in the code, would it be =
something like this?
> > https://gist.github.com/SakiTakamachi/8292dbfe92a2029a6c7b506b12296b7d
> >
> > Admittedly, I don't think this is intuitive either.
>
> That might not be intuitive to you, but it follows directly from the spec=
ified semantics: whether a function is called in `strict_types` mode or not=
, depends only on where the function is called. I personally doubt that the=
re is an easy way to adjust the rule in order to make it both =E2=80=9Cintu=
itive=E2=80=9D and simple.
>
> >
> > [...]
> >
> > When considering the inheritance of strict_types, I think that it shoul=
d be an attribute that can be set in =E2=80=9Cphp.ini" instead of being spe=
cified for each file.
> >
> > What do you think?
>
> Beware that there are many third-party packages that have not opted for `=
strict_types=3D1`; if you enable that mode globally, you might make those p=
ackages malfunction.
>
> As I have just checked, among the packages I=E2=80=99ve installed via com=
poser, there are more packages that do not use `strict_types=3D1`, than pac=
kages that use it. Among those that don=E2=80=99t use `strict_types`, the f=
ollowing ones are fairly common:
>
> google/apiclient
> league/oauth2-client
> michelf/php-markdown
> microsoft/microsoft-graph
> phpmailer/phpmailer
> phpoffice/phpspreadsheet
> phpseclib/phpseclib
>
> =E2=80=94Claude
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>