On 25 March 2025 18:14:21 GMT, Daniel Scherzer <daniel.e.scher...@gmail.com>
wrote:
>On Tue, Mar 25, 2025 at 11:01 AM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
>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]
