Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120950
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> <CAJmy8YEp_1+Z=jeQ_V7jg5ZOuQ7At9Pt=HsJfnS+WuuwPSei8A@mail.gmail.com>
In-Reply-To: <CAJmy8YEp_1+Z=jeQ_V7jg5ZOuQ7At9Pt=HsJfnS+WuuwPSei8A@mail.gmail.com>
Date: Tue, 29 Aug 2023 18:40:12 +0200
Message-ID: <CAJmy8YE=8zYoEfszNkAMeyiVT3uULP-LzPcBa85QOkSoghOnPQ@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)

* I think most code actually using strict_types=3D1 is built with the
assumption that internal functions use strict too, so it's entirely
possible that the backwards-compatibility issue is so small that we
can get away with internal functions just inheriting the userland
strict_types

On Tue, 29 Aug 2023 at 18:36, Hans Henrik Bergan <divinity76@gmail.com> wro=
te:
>
> 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 `=
strict_types` mode from its calling code, and this is not specific to inter=
nal functions.
> > >>
> > >> If you intend to change that for internal functions (with proper dep=
recation period, of course), you might consider making such a behaviour als=
o possible for userland functions (probably using some opt-in); so that fut=
ure 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 b=
e something like this?
> > > https://gist.github.com/SakiTakamachi/8292dbfe92a2029a6c7b506b12296b7=
d
> > >
> > > Admittedly, I don't think this is intuitive either.
> >
> > That might not be intuitive to you, but it follows directly from the sp=
ecified semantics: whether a function is called in `strict_types` mode or n=
ot, depends only on where the function is called. I personally doubt that t=
here is an easy way to adjust the rule in order to make it both =E2=80=9Cin=
tuitive=E2=80=9D and simple.
> >
> > >
> > > [...]
> > >
> > > When considering the inheritance of strict_types, I think that it sho=
uld be an attribute that can be set in =E2=80=9Cphp.ini" instead of being s=
pecified 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=
 packages malfunction.
> >
> > As I have just checked, among the packages I=E2=80=99ve installed via c=
omposer, there are more packages that do not use `strict_types=3D1`, than p=
ackages that use it. Among those that don=E2=80=99t use `strict_types`, the=
 following 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
> >