php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #76312 Returning anything in a constructor/destructor/__clone should error
Submitted: 2018-05-08 16:21 UTC Modified: 2021-08-27 11:21 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: requinix@php.net Assigned: cmb (profile)
Status: Wont fix Package: Class/Object related
PHP Version: 7.2.5 OS:
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
49 + 41 = ?
Subscribe to this entry?

 
 [2018-05-08 16:21 UTC] requinix@php.net 
Description:
------------
Given that __construct and __destruct do not have return types, PHP should raise an error if the user attempts to return a value. Currently it is allowed but the values are ignored. Naturally an empty return should still be allowed.

Targeting only master/7.3+ is fine.

https://3v4l.org/q1guZ

Request or bug? Feels to me like 51% feature request and 49% bug report.

Backwards compatibility? Some quick searches on searchcode.com found some constructors returning values, such as false (private constructors) or $this.

Test script:
---------------
<?php

class Foo {
    
    public function __construct() {
        return 123;
    }
    
    public function __destruct() {
        return 456;
    }
    
}

Expected result:
----------------
Either E_PARSEs or E_WARNINGs. Should be the same one for both methods.

Possibly E_WARNING or E_NOTICE when __construct returns $this: it's understandable but still technically wrong.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-08 16:28 UTC] requinix@php.net 
Actually E_PARSE wouldn't be right.

function(): void { return 123; }

That will fatal with an E_COMPILE_ERROR, so if this went into 7.3+ then it should be the same level. If it went for 7.1 and 7.2 too then an E_COMPILE_WARNING would probably be better, but given the choice I would rather wait for 7.3 and have it be fatal.
 [2018-05-08 16:34 UTC] levim@php.net 
I recommend an E_DEPRECATED for 7.3 and for a fatal in PHP 8.0. This issue has been around for a very long time (appears to be 5.0) and see no value in breaking this suddenly in 7.X.

I'm willing to prepare a patch if this is agreeable.
 [2018-05-08 16:42 UTC] requinix@php.net 
I'm okay with that. I thought a shorter timeframe would be excusable, but following the proper sequence of deprecate now and break later is a safer approach.
 [2018-05-08 16:49 UTC] requinix@php.net
-Summary: Returning anything in a constructor/destructor should error +Summary: Returning anything in a constructor/destructor/__clone should error
 [2018-05-08 16:49 UTC] requinix@php.net 
See also bug #76311, where I just realized this applies to __clone too.
 [2021-08-27 11:21 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-08-27 11:21 UTC] cmb@php.net 
For __clone(), it is now allowed to specify void as return type,
what will catch any return value.

For __construct() and __destruct(), there was a respective RFC[1],
but that had been declined, so this ticket can be closed.

[1] <https://wiki.php.net/rfc/make_ctor_ret_void>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 07:00:01 2025 UTC