Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115721
To: Jordan LeDoux <jordan.ledoux@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAMrTa2HYeKaE9E+A81HvSykpAD8ctd6aK9vtg_U15bYjyjzLKA@mail.gmail.com>
Message-ID: <64b3800a-c54e-c1cc-8bab-bc503a969c37@allenjb.me.uk>
Date: Sat, 14 Aug 2021 15:01:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CAMrTa2HYeKaE9E+A81HvSykpAD8ctd6aK9vtg_U15bYjyjzLKA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Never For Argument Types
From: php.lists@allenjb.me.uk (AllenJB)


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.