Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109588
MIME-Version: 1.0
References: <CAP=4hC+9duSVcREvwOD3jZv+5fmqQzzR=UEraw4Yr6P+b+FfaQ@mail.gmail.com>
 <90F4B395-F010-4196-9C40-7896D4F3F2F4@gmail.com>
In-Reply-To: <90F4B395-F010-4196-9C40-7896D4F3F2F4@gmail.com>
Date: Sat, 11 Apr 2020 22:40:59 +0200
Message-ID: <CAP=4hC+moKGF-XyGuaYEzc54tJb++5bUxCpF-8vXxsPS+NHuUw@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c0b8b305a309de0a"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Ensure correct magic methods'
 signatures when typed
From: carusogabriel34@gmail.com (Gabriel Caruso)

--000000000000c0b8b305a309de0a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 7 Apr 2020 at 12:55, Claude Pache <claude.pache@gmail.com> wrote:

>
> Le 5 avr. 2020 =C3=A0 16:01, Gabriel Caruso <carusogabriel34@gmail.com> a
> =C3=A9crit :
>
> Hello, internals.
>
> Hereby you can find the RFC Document that I want to discuss as suggested
> via https://externals.io/message/109416 and
> https://externals.io/message/107990:
>
> https://wiki.php.net/rfc/magic-methods-signature
>
> Best regards,
>
> -- Gabriel Caruso
>
>
> Hi,
>

Hello Claude,


>
> Regarding __construct(), etc. Since those methods are not supposed to
> return anything, they ought to accept the `void` return pseudo-type in
> their signature, which means exactly that: =E2=80=9Cdo not return anythin=
g=E2=80=9D. I
> consider that the current behaviour (i.e., not accepting the `: void`
> signature) as a bug, and was very surprised when I stumbled on it.
>
>
I'll add to the RFC adding the possibility of typing the `__construct()` as
`: void` as one of the changes.


> ------------
>
> Also, I raise the following question:
>
> Should omitted types be added implicitly? I.e., if I write:  `function
> __toString() { }` should the compiler interpret it as `function
> __toString(): string { }` ? (Currently, it is not the case.)
>
> Doing so would raise BC concerns for some, uh, creative uses of magic
> methods. On the other hand, that may help to add progressively type
> informations on magic methods, since there is no need to synchronise
> manually classes and subclasses (the compiler would do it automatically f=
or
> you). Concrete example here: https://3v4l.org/hTMvA
>
>
This RFC does not cover analyzing the return of magic methods nor adding
simplicity types. I'll add a note about it in the RFC.


> =E2=80=94Claude
>

Thanks!

--000000000000c0b8b305a309de0a--