> // strict with internal func
> declare(strict_types=1);
> declare(strict_types='strict_with_internal_func');
> declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC);
I made a mistake. Here is exactly:
```
// strict with internal func
declare(strict_types=2);
I also skimmed over past discussions.
I've found that having full control over `strict_types` globally is not a good
idea. This is because it can break the behavior of many libraries, and
developers don't always respond appropriately to this fix.
So I came up with the following idea.
Allows a
> That might not be intuitive to you, but it follows directly from the
> specified semantics: whether a function is called in `strict_types` mode or
> not, depends only on where the function is called. I personally doubt that
> there is an easy way to adjust the rule in order to make it both
> Le 29 août 2023 à 18:40, Hans Henrik Bergan a écrit :
>
> * I think most code actually using strict_types=1 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
* I think most code actually using strict_types=1 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
maybe we could do a
declare(internal_strict_types=1);
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 wrote:
>
>
>
> > Le 29 août 2023 à 15:19, Saki Takamachi a écrit :
> >
> >> Hi,
> >>
> >> The
On Thu, Aug 24, 2023 at 1:27 PM Jakub Zelenka wrote:
> Hello,
>
> This is just a reminder that the PHP-8.3 git branch will be created on
> Tuesday 29th Aug 2023. It means that the fixes for 8.3 will need to target
> PHP-8.3 branch and master will be essentially for PHP 8.4. Also don't
> forget
> Le 29 août 2023 à 15:19, Saki Takamachi a écrit :
>
>> 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
>> internal functions.
>>
>> If you intend to change that for internal functions
On Tue, Aug 29, 2023, at 1:57 AM, Levi Morrison via internals wrote:
> On Sun, Aug 27, 2023 at 4:20 AM Tim Düsterhus wrote:
>>
>> Hi Athos
>>
>> On 8/27/23 04:02, Athos Ribeiro wrote:
>> > I am moving this RFC [1] to the voting phase. Voting will be open for the
>> > next 2 weeks, until
Hi, internals.
I thought about various things to improve the current situation where
`PDO::ATTR_ERRMODE` is not working very smartly.
Exceptions may be thrown regardless of the setting of `PDO::ATTR_ERRMODE`.
https://www.php.net/manual/en/pdo.rollback.php#refsect1-pdo.rollback-errors
Another
> 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
> internal functions.
>
> If you intend to change that for internal functions (with proper deprecation
> period, of course), you might consider
> Heya!
>
> I was not aware that strict types didn't work here. While I'm 100% behind
> the idea, I am afraid that changing this will break code in currently
> strict files where the assumption was made that it already worked like
> that. It would probably have to give deprecation notices first,
> Le 29 août 2023 à 02:46, Saki Takamachi a écrit :
>
> Hello.
>
> I’m Saki Takamachi.
>
> Inspired by the issue below, I'm thinking of proposing this RFC.
> https://github.com/php/php-src/issues/12055
>
> As the documentation below states, PHP's internal functions currently ignore
>
On Tue, Aug 29, 2023 at 2:46 AM Saki Takamachi wrote:
> Hello.
>
> I’m Saki Takamachi.
>
> Inspired by the issue below, I'm thinking of proposing this RFC.
> https://github.com/php/php-src/issues/12055
>
> As the documentation below states, PHP's internal functions currently
> ignore
14 matches
Mail list logo
