Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130036
Message-ID: <0ece40da-762a-4190-9cc8-23ff432fd441@bastelstu.be>
Date: Fri, 6 Feb 2026 20:59:05 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [IDEA for RFC] let the "new" operator fail when the
 __construct() function returns a value.
To: Mirco Babin <mirco.babin@gmail.com>, internals@lists.php.net
References: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 2/2/26 19:00, Mirco Babin wrote:
> # RFC
> 
> I've been asked to follow the RFC process. And I've been told that the
> rejected PHP RFC Make constructors and destructors return void
> ( https://wiki.php.net/rfc/make_ctor_ret_void ) rejects my proposal.
> However, my proposal is explicitly about the "new" operator and not
> about return types. It does, however, concern return values.

Personally I find the fact that it's illegal to define a return type on 
`__construct()` to be a pretty good indication that the constructor is 
not meant to be able to return anything. As such I'm a little surprised 
by the disagreement in that RFC, though it should be noted that a 
majority was in favor (just not a 2/3's majority).

It would definitely make sense to me to revisit this topic and also 
disallow __construct() to be a Generator. That is a great find you made 
there!

> I am very very reluctant to follow the RFC process myself:

I'd like to encourage you going through the RFC process. It is less 
complicated that it may seem at first and from my experience, the folks 
on this list are very supportive of new contributors.

> * It would take up a lot of my free time. I would write the RFC first in
>    Dutch, my native language, and then translate it into English. This is
>    because I speak and write English, but don't understand all the nuances
>    of (American/Australian/British/Canadian/Irish/Nigerian/...) English.

I'd say that the majority of folks on this list are not native speakers 
of English. You definitely don't need to have a perfect English 
vocabulary and grammar to be able to write an RFC. In fact using simple 
language is often preferable, since the purpose of an RFC is to 
accurately describe a technical topic to a wide audience with differing 
levels of English knowledge. You are not trying to write a novel that 
should sound nice.

For the topic at hand it's also a very straight-forward proposal that I 
don't think needs much explanation: Disallow returning values from 
`__construct()`. It's a good start to get your feet wet.

> * While I do have some knowledge of C and the php-src codebase, writing a
>    PR to implement the RFC would take up a significant amount of my
>    free time.

You don't necessarily need to do the implementation (entirely) yourself. 
It definitely helps to have an implementation to figure out the edge 
cases, but as mentioned above, I don't think there are that many edge 
cases here.

I expect it to be in scope of the Foundation developers to create an 
implementation for an “outside RFC” that was accepted by the community. 
To me this sounds like a good use of the Foundation funds, but I can't 
speak for certain :-)

> * The True Async RFC has demonstrated that the author of an RFC must have
>    a certain degree of trustworthiness. And I, as a passerby, have not
>    established any trustworthiness.

The True Async RFC is a very complex RFC that touches many fundamental 
parts of PHP and thus has a “large scope” that needs to be taken into 
account. It is a quite different beast from what we are discussing here.

> * The voting process of an RFC is highly uncertain and can lead to
>    rejection. The whole process could ultimately be a complete waste
>    of my time.

I wouldn't say that the voting process is *highly* uncertain. For a 
majority of RFCs the results are quite clear (often unanimous). 
Rejection is always a possibility, but even then I wouldn't say it's a 
waste of time per se: The discussion will provide valuable insight for 
the greater community. In any case …

> Anyone who would like to create an RFC for this, please go ahead.

… the time investment would equally apply to anyone else writing an RFC 
on your behalf. In fact it would possibly be even larger, since they 
would have to become familiar with the issue first, whereas you already 
encountered in practice, so you already have an idea of what needs to 
change and *just* need to write it down.

----------

All that said: If you are willing prepare an initial RFC Draft based on 
the official RFC template (https://wiki.php.net/rfc/template) and to go 
through the process of officially discussion the RFC, I'm happy to do 
the “polishing” work as an official coauthor / mentor to make sure there 
are no missing bits or other mistakes. I'm also willing to get someone 
to do the implementation (potentially I'm doing it myself).

Do we have a deal? :-)

Best regards
Tim Düsterhus