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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: requinix@php.net
New email:
PHP Version: OS:

 

 [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-2024 The PHP Group
All rights reserved. 		Last updated: Fri Dec 27 17:01:30 2024 UTC