On Mon, 6 Jan 2020 at 10:29, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:
> Hello George
>
> On Mon, 6 Jan 2020 at 01:28, G. P. B. <george.banyard@gmail.com> wrote:
>
>> On Sun, 5 Jan 2020 at 18:44, Gabriel Caruso <carusogabriel34@gmail.com>
>> wrote:
>>
>>> Hello Internals,
>>>
>>> I have a PR proposing to start checking the signatures for PHP magic
>>> methods in the next major version of PHP:
>>> https://github.com/php/php-src/pull/4177. The idea for this PR came from
>>> https://bugs.php.net/bug.php?id=69718.
>>>
>>> I'd like to hear your opinion before putting more effort into this :)
>>>
>>> Best regards.
>>>
>>
>> Hello Gabriel,
>>
>> I do like the idea, but I would agree that I'd want void as the return
>> type instead of a no return compile error.
>> Other than that +1 from my side.
>>
>
>
> The reason why I didn't want to go with `__construct(): void`, for
> example, is because some articles that I've read say that Constructors and
> Destructors do not return anything:
>
> - https://www.geeksforgeeks.org/php-constructors-and-destructors/
> - https://docs.phpdoc.org/references/phpdoc/tags/return.html
> - https://stackoverflow.com/questions/11904255/constructor-returning-value
>
> Also, the community has pushing this standard, as it can be seen in
> https://github.com/slevomat/coding-standard#slevomatcodingstandardtypehintsreturntypehint-
> .
>
> Best regards,
>
Well the void return type means no return or an early return, so I would
say that "no return" is a stronger requirement then void, but I think
adding the void return type is a massive BC break as all code which doesn't
define the magic methods as void break ... I didn't think that through as
it seems the no return thing doesn't have that problem, so seems fine by me
however this is done.
Best regards
George P. Banyard
