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
