Most of the internals who voted no, as far as I know, did so due to
subjective reasons (i. e. don't want to allow declaring
constructors/destructors as `void`).
I don't think that should affect on what you believe is a change for better
or for worse.
As I mentioned before, it doesn't make much sense to allow `__clone` to be
declared as `void` and make constructors/destructors an exception.
As for the BC break, yes, only people who return something from a
constructor/destructor are in trouble and will get a deprecation warning in
On Fri, Jul 3, 2020, 3:47 PM Peter Bowyer <firstname.lastname@example.org> wrote:
> I have voted in favour, but enough people I respect have voted against to
> make me reconsider.
> My understanding is the changes will only cause problems to people who
> have returned something from __construct() or __destruct(). As people
> shouldn't have done this, IMO it is a smaller BC issue than the BC break
> that would have been caused if the proposed # attribute syntax had been
> On Thu, 2 Jul 2020 at 22:12, Benas IML email@example.com> wrote:
>> Hey internals,
>> I have opened the voting for the RFC, let's hope everything is going
>> to be smooth :). If you have any other questions, let me know!
>> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>> Best regards,
>> Benas Seliuginas
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php