Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89037
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56372B62.1000206@gmail.com>
References: <CAEbg-4Z3_KA=EtEabyALyDUB5SjhjVmgSkz3tdozuNdU3Prm-Q@mail.gmail.com>
	<56372B62.1000206@gmail.com>
Date: Mon, 2 Nov 2015 14:12:31 +0300
Message-ID: <CAEbg-4ZOept=K1mv9KM8-7Zk_Om2h6Q1ixVS4yDiVo-MB+Z96g@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2400080e49505238cda24
Subject: Re: [PHP-DEV] [Question] Variadic method signature compatibility
 between 5.6 and 7.0
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--001a11c2400080e49505238cda24
Content-Type: text/plain; charset=UTF-8

2015-11-02 12:22 GMT+03:00 Rowan Collins <rowan.collins@gmail.com>:

> Should they? func_get_args() can be used to simulate any function
> signature, so you could equally say that the following are "compatible":



Hello! Thank you for the answer.
However, question is not about func_get_args() at all, it can be removed to
simplify an example. However, I still have a doubts that these two
signatures are not compatible.

First definition declares exactly one single parameter, which can be absent
during the method call, so I can even write

public static function test() {}

Second definition defines zero or more arguments, so it can be also
described by the same signature:

public static function test() {}

Signature with variadic args will be incompatible if the first definition
requires additional arguments before optional and second signature doesn't
respect this, see https://3v4l.org/5Fsou (this behaviour is correct and
warnings are expected).

But if the number of required parameters are matching, then whole signature
should be matching. PHP5.6 with HHVM prove this fact, see:
https://3v4l.org/YCmPS, and PHP7.0 probably doesn't play well.

If you think, that the new logic in PHP7.0 is correct, then it should be
nice to have a small notice in BC change with PHP5.6 logic, somewhere in
http://php.net/manual/en/migration70.incompatible.php#migration70.incompatible.other.func-parameters
.

--001a11c2400080e49505238cda24--