# Idea: Implicit inheriting function argument & return type-hint

- Thread: https://externals.io/message/122590
- Original archive: https://news-web.php.net/php.internals/122590
- Started by Marc on 2024-03-09T07:18:56+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #122590 — Marc — 2024-03-09T07:18:56+00:00

URL: https://externals.io/message/122590#122590

Hi internals,

Based on the discussion of "Property accessor hooks, take 2​" and the 
set-hook argument type - I got to wonder why we still define "no type" 
as `mixed`.

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
}
class C extends A {
     public function typed(mixed $var):mixed { return $var; } // 
explicit mixed to widen the type
}

That do you think?

This is just something that come to mind without having the knowledge 
nor time for this kind of RFC or implementation.

Greetings,
Marc

---

## #122593 — Christian Schneider — 2024-03-09T14:17:38+00:00

URL: https://externals.io/message/122590#122593 · In reply to: #122590

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

---

## #122599 — Stephen Reay — 2024-03-10T04:18:26+00:00

URL: https://externals.io/message/122590#122599 · In reply to: #122593

> 
> Am 09.03.2024 um 08:18 schrieb Marc <marc@mabe.berlin>:
> > […]
> 
> 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