Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92811
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.65 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Jesse Schalken" <me@jesseschalken.com>
Cc: "PHP internals" <internals@lists.php.net>
References: <CAOsHV+vDNGNThMDZU7_ZkTr2janDVmbjmNkuSGSc=3opLcPE-g@mail.gmail.com> <CAF1yvATUn2Dj6KWTR3hz1N=MJU=sK3zNrfvnjp8dJPYTQixLUQ@mail.gmail.com> <op.ygdbthuec9evq2@nikita-pc> <CAF1yvARt7TeAG+RvDCaPjsCeJAT_jSg6n_dAWwgjNnJvO-Rj=g@mail.gmail.com>
Date: Tue, 26 Apr 2016 20:55:20 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.ygjf2ibbc9evq2@nikita-work-box>
In-Reply-To: <CAF1yvARt7TeAG+RvDCaPjsCeJAT_jSg6n_dAWwgjNnJvO-Rj=g@mail.gmail.com>
User-Agent: Opera Mail/12.16 (Linux)
Subject: Re: [PHP-DEV][RFC] Callable Types
From: inefedor@gmail.com ("Nikita Nefedov")

On Sat, 23 Apr 2016 20:44:27 +0300, Jesse Schalken <me@jesseschalken.com>  
wrote:

> I see. So it's the combination of not erroring when more parameters are  
> passed than a function accepts, and >permitting methods to add extra  
> optional parameters that is wrong. So without the former being  
> fix/deprecated, >the correct thing to do is to disallow extra optional  
> params. Makes sense.
>
> Are there any valid use cases for passing extra parameters to a function  
> any more, now that there is the varargs >syntax to replace  
> func_get_args()? If not, maybe it could be deprecated by this RFC.
>
> Regarding references, by-ref invariance for parameters makes sense, and  
> is what method compatibility does. >According to method compatibility  
> and call-time behaviour however, return by-ref is effectively a subtype  
> of >return by-value:
>
>> function &returns_ref() {
>>    $f = 0;
>>    return $f;
>> }
>>
>>>> function returns_val() {
>>    return 1;
>> }
>>
>>>> $v1 = returns_ref(); // ok
>> $v2 =& returns_ref(); // ok
>> $v3 = returns_val(); // ok
>> $v4 =& returns_val(); // Notice: Only variables should be assigned by  
>> reference
>>
>> interface Methods {
>>    function &returnsRef();
>>    function returnsVal();
>> }
>>
>>>> class ReturnRef implements Methods {
>>    function &returnsRef() {} // ok
>>    function &returnsVal() {} // ok
>> }
>>
>>>> class ReturnVal implements Methods {
>>    function returnsRef() {} // Fatal error: Declaration of  
>> ReturnVal::returnsRef() must be compatible with >>&  
>> Methods::returnsRef()
>>    function returnsVal() {} // ok
>> }
>
> Otherwise it LGTM
>
> cheers

Hey,

sorry for slow reply, been busy working...

I don't really see use cases for func_get_args any more, variadics do
it better (more obvious/documentative for the caller). But this is
a huge BC break, I'm afraid it could be deprecated only in 8.0
and still that would be pretty big of an event... Definitely a matter
of another RFC.

You're right about return references, I've made changes in the RFC
about it. There's a problem with syntax though. So now passing a
function that returns a reference to a parameter that expects value
returning function is working. But you can't declare in the callable
typehint that you only need functions that return reference.
That is, apart from syntax limitations, I'm always happy to
discourage usage of references :P

Touching optional parameters again - there was also my oversight,
actually passing function with optional parameters is fine
*as long as they are not typed*. Otherwise it can lead to
weird type errors. So that was changed as well.

Thanks to 3v4l guys, all these changes are on https://3v4l.org/
already, you can check them out :)