Re: Idea: Implicit inheriting function argument & return type-hint
| From: | Stephen Reay | Date: | Sun, 10 Mar 2024 04:18:26 +0000 |
| Subject: | Re: Idea: Implicit inheriting function argument & return type-hint | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122599@lists.php.net to get a copy of this message | ||
> On 9 Mar 2024, at 21:27, Christian Schneider <cschneid@cschneid.com> wrote:
> Am 09.03.2024 um 08:18 schrieb Marc <marc@mabe.berlin>:
>> As the pseudo type
mixed exists since PHP 8.0, which is
>> already out-of-date, I have the feeling it would be better to force people to explicitly write
>> mixed to widen the type of an overwritten function and let "no
>> type" inherit the argument and return type of the parent.
>>
>> Example:
>>
>> class A {
>> public function typed(int $var): int { return $var; }
>> public function untyped($var) { return $var; } // implicit mixed as no overwrite
>> }
>> class B extends A {
>> public function typed($var) { return $var; } // implicit int as inherited from
>> overwritten function
>> }
>
> This sounds like a bad idea to me as I cannot look at the function definition in class B and
> determine what the type of $var is.
> On top of that: If the type of $var in A is changed then it would automatically also change in
> B. While this seems convenient it could also break B in subtle ways as the function suddenly gets
> different types than expected.
>
> Regards,
> - Chris
I guess my discussion with Larry was at least part of what you're referring to.
The proposal here would introduce the same problem as we discussed on the other RFC: inconsistency
with what people are used to elsewhere in the language (eg untyped properties).
It also means that existing code would have the complete opposite effect to previously, making it a
huge BC break. You'd likely have to have two stages: deprecate and then remove use of untyped
parameters, and then reintroduce untyped to mean "inherited" type, which still suffers
from the issues Christian pointed out.
I could get behind the "first half" of that process: making a type required (ie
deprecating type-less parameters/properties) but I doubt there's enough support for that to
pass a vote.
Cheers
Stephen