Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121565
Content-Type: multipart/alternative;
 boundary="------------DqL1sSOsE50uvYqIMk6Ul7DW"
Message-ID: <5ea314c4-f45d-4b7c-a94d-a82931eeb80b@daniil.it>
Date: Fri, 3 Nov 2023 14:15:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: internals@lists.php.net
References: <CAJpLVh1P0kTneo+chFEdp2oCmSKNpgpDxSXd3atv9OHKejABgw@mail.gmail.com>
 <e5d9a346-015c-48d5-baa8-4742c78b600f@daniil.it>
 <CAPyj-LAfKEoOvaxMn1ggXcw4jaUfOzXEMAnMLydZq84tQGva6A@mail.gmail.com>
In-Reply-To: <CAPyj-LAfKEoOvaxMn1ggXcw4jaUfOzXEMAnMLydZq84tQGva6A@mail.gmail.com>
Subject: Re: [PHP-DEV] Previous discussions about generics syntax only?
From: daniil@daniil.it (Daniil Gentili)

--------------DqL1sSOsE50uvYqIMk6Ul7DW
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ilija,

> The optimizer, including type inference, is limited to the scope of
> the current file (along with internal functions/classes). [...]
> Preloading is the exception, where all preloaded files can assume not
> to be changed after PHP has booted.

Well, I was actually thinking of enabling these compile-time checks only 
if preloading is enabled, to ensure the closed-world guarantee.

> We could make type checking a CLI step but how is that really better than
> PHPStan or Psalm at that point

Yeah don't really like the idea of a separate "typechecking" step 
either, I'd really love for this to be an integral part of the execution 
process, not as a separate static analysis step.

> PHPStan and Psalm are arguably successful *because* they are
> written in PHP, making them much easier to maintain and contribute to.
Agreed, however if at least some static analysis functionality is 
already implemented, I see no reason to not make use of it, even if
> PHP does not accurately represent arrays in the optimizer and has no notion of array shapes.
personally I really like array shapes but *only* as a stopgap measure 
while switching to full object DTOs, so I'm comfortable with the idea of 
not having static analysis for array shapes (actually, I would 
absolutely love to just treat all array values as mixed during static 
analysis, though array/list generics might be nice and easy to 
implement...).
> Another issue, specifically pertaining to generics, is that PHP has
> type coercion. In both weak and strict typing mode, a float function
> parameter will coerce an integer value. However, if generic types are
> erased at runtime then the VM cannot do coercion for foo<float>($int)
> (where function foo<T>(T $var)). This will require either accepting
> inaccurate runtime types, or establishing stricter static rules that
> do not match the existing behavior.

Well I'm all for stricter rules :)


Regards,

Daniil Gentili.

--------------DqL1sSOsE50uvYqIMk6Ul7DW--