On 14/08/2021 00:27, Jordan LeDoux wrote:
Hey internals,

I've been working on the draft for my operator overloading RFC, and in
doing so I encountered a separate change that I would like to see.

That is, the use of `never` as an argument type for interfaces. Since
arguments in PHP are contravariant to preserve Liskov substitution, `never`
as the bottom type should indicate that implementing classes can require
any type combination they want. This is in fact consistent with type theory
and set theory, and is how the bottom type is treated in several other
languages.

In this case, the bottom type would be used to indicate covariant parameter
polymorphism while not conflicting with LSP.

This would provide a sort of minimal form of generics to PHP without the
issues that actual generics present from an implementation perspective. It
would not, however, restrict or hinder any future RFC for generics.

This is at the first draft stage, and I currently have the RFC on a github
repo to allow for easy contribution and collaboration.

Any feedback is greatly appreciated.

https://github.com/JordanRL/never-argument-type

Jordan

Whilst I understand there's a historical aspect to the keyword naming used in this RFC, as a PHP developer, I think the use of "never" here is going to be confusing to people when considered along-side the never return type.

I think it would make more sense to change the keyword for this RFC to something else such as "any", "unspecified", "unknown" or "specify". (Whilst "nothing" might also be considered given its use in other languages, I don't think the meaning / purpose is that clear).

This RFC only considers this feature for arguments. Why is it also not a valid feature for return types? I think it might be useful for abstract classes and interfaces (for example, the Iterator interface) to force implementers to specify a return type for certain methods whilst not specifying anything about it themselves.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to