Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109624 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98405 invoked from network); 14 Apr 2020 14:40:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Apr 2020 14:40:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7407C1804C3 for ; Tue, 14 Apr 2020 06:09:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 14 Apr 2020 06:09:42 -0700 (PDT) Received: by mail-il1-f173.google.com with SMTP id c17so8114171ilk.6 for ; Tue, 14 Apr 2020 06:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vm8CWB4c//DAKrdlt/jcqIbZnMp0wjgRKgOPKce7P4M=; b=Rrdqn3NPgLA2kbXkP2b/Ee0OloHmuuzCLyRtecJ2OxS2r5+1nL5Jnp1J+uKr9waSWv EHxafULy1RgzKCub0arFTR0VzGkirPzaSWdcmXoECACfbpM9Eg50hYjEYiwSXDv7tp2R RsgfBdiFmb5nqBOBqKaa3x0GcCm9IYjC3JRTSkjfGG3PYN3zcD8Gy1P5hF8z8JioC3BB Brs/fQ24C8q1H9f5zEYlDyL2sO2hhBdBDhdzre4jAR1V6EvBt3WVr1ez8LJ6PQECR8OA X8CqweJOYmBqA36b3t0J3W7PVvaKdfSQ4D0NPO1AWrLGKtqRYLXJt2ZZUDzpdlX6m+x6 KIGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vm8CWB4c//DAKrdlt/jcqIbZnMp0wjgRKgOPKce7P4M=; b=pP+L0/XSwnPOOXOnkR+agztP44i84ZDo7V3yM1dsiSY2rV6Q3MSerYp4rzBWdWDwy5 HtNIO7gOgpaG9fmAsfMmcPxXU8Jspmf3aa3jDKv3rhAt/Uyf9MJ3DHkd+harsTwrzEl2 GCj83A7OoXtILIIFgVlJQh+wUzlAMMPEB9Zm4IdDbUN7mWe+dOCKikoq9HEDTwIDhcyF fdlXhawpXbHxVzlap0LG8vG7fLLmL9UzShKFGSlt/sRrb1lIT8Off1gcTO97UgJFFVD6 q1p1GUuqRULNxKJPBMjoA+kj/jfJqNJZJ1Wj3V50OoXamJcglFpre8oaM6aGEp78zT2A kvvQ== X-Gm-Message-State: AGi0PuYhUkDBp3UF2PQINGhtePzIb8Hi+7Dt7tWCaVpnfd5qK3MUPRR0 Kfg/qdV22T5oNM9cIkPXHNVFUwG7Cc4hNv75WQk= X-Google-Smtp-Source: APiQypJqs7BESzq1vh47nihj1mu0qWhxAjjU/l8G2NMKaNLBmmcKwP9Ht24lrRj1EZ0JhEh0AuUEpxAtEekPx3EDYh0= X-Received: by 2002:a92:409a:: with SMTP id d26mr90474ill.153.1586869781552; Tue, 14 Apr 2020 06:09:41 -0700 (PDT) MIME-Version: 1.0 References: <90F4B395-F010-4196-9C40-7896D4F3F2F4@gmail.com> In-Reply-To: Date: Tue, 14 Apr 2020 15:09:30 +0200 Message-ID: To: Claude Pache Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000a261aa05a33fe938" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed From: carusogabriel34@gmail.com (Gabriel Caruso) --000000000000a261aa05a33fe938 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 11 Apr 2020 at 23:29, Gabriel Caruso wrote: > On Sat, 11 Apr 2020 at 22:40, Gabriel Caruso > wrote: > >> On Tue, 7 Apr 2020 at 12:55, Claude Pache wrote= : >> >>> >>> Le 5 avr. 2020 =C3=A0 16:01, Gabriel Caruso = a >>> =C3=A9crit : >>> >>> Hello, internals. >>> >>> Hereby you can find the RFC Document that I want to discuss as suggeste= d >>> 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 anyth= ing=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= for >>> 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! >> > > Btw, the problem that you reported about incompatible signatures will be > fixed on PHP 8: https://3v4l.org/hTMvA/rfc#git-php-master. > > I've also added a test on the implementation ensuring the following: > https://3v4l.org/5010J/rfc#git-php-master. > > Thanks! > > -- Gabriel Caruso > RFC and implementation have been updated. I'll open it for voting this Friday (17-04-2020) if there's anything else to discuss. Best regards, --000000000000a261aa05a33fe938--