Hey Máté,
On Tue, Jun 16, 2020, 11:31 AM Máté Kocsis <kocsismat...@gmail.com> 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 both, since introducing the
latter check
> is not just a bug fix, it's a substantial change IMO.
>
> What I would like to avoid for sure is that the void return type is not
actually enforced.
> (Offtopic: It seems that the magic method signature RFC exactly does
this, and I'm not
> happy about it. I'd welcome an amendment RFC to fix the new
inconsistencies).
Since there was a second PR already in the works on dealing with the return
value, I wasn't sure whether it was a good idea to implement that. But, I'm
happy to join forces and will contact the PR's author :)
> Furthermore, I personally also like the concept of an explicit return
type declaration for
>constructors, but Nikita's earlier argument against (that most languages
forbid the explicit
> return type) makes me think. Anyhow, this counterargument might be worth
to add to the RFC.
I should have emphasized more on this but PHP constructors aren't like any
other language constructors, since they are normal methods that can be
called by simply doing `$object->__construct();`.
I'm not sure if any other language allows you to do something similar.
> And regarding the last section of the RFC (Backward Incompatible
Changes), I'm not exactly
> sure what you mean there, but since constructors are exempt to LSP
validation, I think
> it's ok if a child class overrides the parent constructor with a widened
return type.
>
> Regards,
> Máté
What I meant, was that since no return type means `mixed|void`, you can't
do the following:
```
public function __construct(): mixed {}
```
But yes, it is allowed to widen the type from `void` to no return type.
Best regards,
Benas
