On 25 March 2025 18:14:21 GMT, Daniel Scherzer <[email protected]> wrote:
>On Tue, Mar 25, 2025 at 11:01 AM Rowan Tommins [IMSoP] <[email protected]>
>wrote:
>
>>
>> I don't think the language should pretend to support something that it
>> doesn't
>>
>
>I don't see what the pretending is here - the engine supports declaring
>that a method must accept a parameter but makes no promises about the type
>of that parameter
I guess I just struggle to make such a declaration have any meaning; it feels like a philosophical
statement rather than a practical one.
Perhaps "pretend" was too strong in this case; I was mentally comparing it to
Python's unenforced type hints, which are only as reliable as comments; and the occasional
suggestion of doing the same in PHP with generic declarations (built-in syntax with no built-in
behaviour, which would be a hard No from me).
If I assert($foo instanceof InterfaceUsingNever), I can't actually do anything useful with the
promised method; I can only call it if I either read the unenforced rules (e.g. in docblocks and
comments), or assert($foo instanceof SomeConcreteImplementation) instead.
In the context of this thread, I can see that the examples are logically consistent, but if I just
saw one in the wild, I'd just be scratching my head what it means to require that no values are
acceptable.
And I've seen plenty of junior devs struggle with simple things like the difference between
"nullable" and "optional", so I worry that making the type system too rich will
lose PHP its reputation as an approachable language.
It's possible I'd react less strongly if a keyword was chosen that made more sense in
context, although I'm not sure what that would be.
public function foo(int $a, must_override $b);
That's not quite right, I think.
Rowan Tommins
[IMSoP]