Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114053
To: internals@lists.php.net
References: <CAH5C8xUqzFJ4V0uo7_FviMq3Sy9Da3MWNMhh+neMO8ZjEnyQWg@mail.gmail.com>
 <CAF+90c8s0+GvL378hhxnah315ae69_56LO=pMXnQisA5-E-5Lw@mail.gmail.com>
Message-ID: <918bd585-0a5a-063d-7d4e-c89eadef0dde@processus.org>
Date: Wed, 14 Apr 2021 15:46:46 +0200
MIME-Version: 1.0
In-Reply-To: <CAF+90c8s0+GvL378hhxnah315ae69_56LO=pMXnQisA5-E-5Lw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal
 methods
From: pierre-php@processus.org (Pierre)

Le 14/04/2021 à 15:30, Nikita Popov a écrit :
> 1. The one addressed by the RFC is addition of a return type (or more
> generally, restriction of a return type). This is generally done when the
> method was already guaranteed to return that type, and this fact was not
> explicitly declared previously. Direct users of the API are not affected by
> the change. Overriding methods can be affected in two ways: They made use
> of the lose API contract and returned a different type, in which case the
> implementation needs to be changed. Or, and this is almost always the case,
> they already adhere to the stricter API contract, but now need to
> explicitly declare this fact.
>
> 2. The second one not addressed here is the addition of optional
> parameters. Take for example the recent change of mysqli::execute() to
> mysqli::execute(?array $params = null). Once again, direct users of the API
> are not affected by the change. Overriding methods are affected because
> they need to pass through the new parameter. As this is an addition of a
> new optional feature, not passing through the optional parameter only
> becomes a problem if the new optional feature is actually used. Whether not
> passing it is "harmless" depends on whether the API declarer and the API
> user are the same.

Hello,

Having type-inference wouldn't transparently fix some of these issues ?

Let's consider a method such as foo($array) which returns a bool or a 
string, for example. And suddenly, the types get specified as foo(?array 
$array): bool|string.

With type inference, an implementer which has correctly implemented an 
override this signature would inherit from types if non-specified, and 
wouldn't have anything to fix ?

This is just a stupid idea, but I'd love that, not having to repeat all 
types when implementing method interfaces or overriding methods, and 
just trust the compiler and or engine runtime for inferring types when 
checking it, and do it in a smart and robust way so that invalid code 
cannot compile or run, but valid code be easier and quicker to read.

But sorry for the noise, I'm deviating from the original issue.

Cheers,