Hey Christian,
Wrong wording, sorry! :)
> But I definitely wouldn't want a deprecation warning for constructors without
> explicit ': void' as I see no reason to force people to use it.
This RFC proposes 2 things:
1) If a non-void value is returned from a constructor/destructor, a
deprecation
Am 17.06.2020 um 13:59 schrieb Benas IML :
> We should allow newer codebases to enforce `void` rules on
> constructors/destructors by allowing to explicitly declare return type as
> `void`.
I don't see a big benefit in this explicit return type void as newer codebases
hopefully will try to get
Thanks everybody for the replies.
> However, I am also fine if the void return value is only enforced when the
> void return
> type is declared. Additionally, we could emit a deprecation notice/warning
> when
> there is no return type declaration, but a value is returned. I think this
> would
On 17.06.2020 at 11:35, Dan Ackroyd wrote:
> On Tue, 16 Jun 2020 at 01:35, Benas IML wrote:
>>
>> Hey internals,
>>
>> RFC: https://wiki.php.net/rfc/constructor_return_type
>>
>
> Hi Benas,
>
> Instead of deleting RFC docs, please can you update their status to
> 'inactive' or 'replaced by xyz'.
On Tue, 16 Jun 2020 at 01:35, Benas IML wrote:
>
> Hey internals,
>
> RFC: https://wiki.php.net/rfc/constructor_return_type
>
Hi Benas,
Instead of deleting RFC docs, please can you update their status to
'inactive' or 'replaced by xyz'.
The wiki is part of the history of the discussion, and
>
> This PR should also address all of Máté's concerns since it makes
> constructors and destructors always return `void` (even when no explicit
> `void` return type is specified).
To be clear, my main concern was that declaring a void return type
shouldn't be
allowed, unless it's actually
On Wed, Jun 17, 2020 at 9:18 AM Christian Schneider
wrote:
> Am 16.06.2020 um 21:30 schrieb Benas IML :
> > I put the original RFC on hold and created a new PR [0] for implicitly
> > enforcing `void` rules on both constructors and destructors. Note, that
> > this results in a BC break since it
Am 16.06.2020 um 21:30 schrieb Benas IML :
> I put the original RFC on hold and created a new PR [0] for implicitly
> enforcing `void` rules on both constructors and destructors. Note, that
> this results in a BC break since it is no longer legal to return non-void
> value from
On Tue, 16 Jun 2020 at 13:59, Dan Ackroyd wrote:
> To be clear, I'm not sure if I am in favour or against the RFC. The
> real problem is that constructors just don't fit into how we think
> about normal functions is PHP, because of the magic that goes on
> around them and so both void and null
Nope, that isn't changing.
I simply wanted to point out that this RFC is proposing to allow to declare
constructor return type as `: void`, but not as `: mixed`.
The entire RFC is just a matter of cosmetic addition allowing to add `:
void` to constructors/destructors (for those that want to).
On 16.06.2020 at 16:19, Benas IML wrote:
> I meant something like this:
> ```
> class Test {
> public function __construct() {}
> }
>
> class Test2 extends Test {
> /* this is legal */
> public function __construct(): void {}
> }
>
> class Test3 extends Test {
> /*
> * this
Exactly :)
Personally, I have numerous times caught myself declaring constructors `:
void` too. I would love to have everything consistent and all methods to
have a return type.
Although, I do understand that not everybody agrees with me and that's why
this RFC isn't planning to ever force
Hey Dan,
Thanks for your reply.
> No return type is _treated as_ 'mixed|void' in some circumstances
Could you elaborate? No return type DOES mean `mixed|void`, could you give
any pointers as to where that is different?
> I'm actually not sure exactly what you're trying to say there
I meant
>From a PHP developer's POV - when writing a class or refactoring one. I
have to catch myself all the time trying to declare ": void" on the
constructor. It's mostly a habit from doing so with the other methods in
the class. I lean in favor of being able to declare a void return type on a
G.P.B. wrote:
> Seems like a no brainer and a good addition. :)
For situations where stuff is simple, 'no brainers' are okay.
For situations where everything is horribly convoluted, 'no brainers'
are often bad.
Benas IML wrote:
> even though no return type means mixed|void
Not quite.
No return
Hey Máté,
On Tue, Jun 16, 2020, 11:31 AM Máté Kocsis wrote:
> Hi Benas,
> Overall, I'm very much in favour of disallowing returning a value from
constructors.
> However, I think the RFC should deal with the return value and the
signature validation
> in the same time, so that we can vote about
Hi Benas,
Overall, I'm very much in favour of disallowing returning a value from
constructors.
However, I think the RFC should deal with the return value and the
signature validation
in the same time, so that we can vote about both, since introducing the
latter check
is not just a bug fix, it's a
On Tue, 16 Jun 2020 at 02:35, Benas IML wrote:
> Hey internals,
>
> I am proposing to allow void return type for constructors/destructors.
> Note,
> that this is an **optional** and cosmetic-only addition! All of the
> reasoning
> is in the RFC.
>
> RFC:
Hey internals,
I am proposing to allow void return type for constructors/destructors. Note,
that this is an **optional** and cosmetic-only addition! All of the
reasoning
is in the RFC.
RFC: https://wiki.php.net/rfc/constructor_return_type
Best regards,
Benas
19 matches
Mail list logo
