Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110567 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 58180 invoked from network); 16 Jun 2020 09:46:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jun 2020 09:46:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 46EAA1804E1 for ; Tue, 16 Jun 2020 01:31:51 -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-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (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, 16 Jun 2020 01:31:50 -0700 (PDT) Received: by mail-vs1-f53.google.com with SMTP id u17so10972048vsu.7 for ; Tue, 16 Jun 2020 01:31:50 -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=7lMhbZVPkW4FIZIBdNBS+NKTcVAdlWZ5sqeRBjkgKbs=; b=SN/8gVwSvdjiqhJkHW2oY61KpGmPCc0rVS5uWFJbLLLiSAIePTb9yemtt/Ya+0o39D IBGwJcEkNy0Lid8i+Rt8izqd2amtcWtVyXyONoyJUvtFvEfR48u2W++Zw4ODvDT9IO6H TzUvBOfi9zBf+fJ/pcBw8w5WhdMj0IKyVPNpzlI4cPjSTPLvaC216QCNXxpCE2EKFC70 Biw2re5Vq0ZTtMnyRZPwKqBdMwvegieUIChtLzQmtpnHhHtP6j1PE68vf6Qj7mNCI91+ DYyzZHwC/UOpOFXAJ8prdwwgWKPAorCRm9AkciVUFBogsMiu+A0iIMnqGsUNHJ8pijFy jRgw== 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=7lMhbZVPkW4FIZIBdNBS+NKTcVAdlWZ5sqeRBjkgKbs=; b=EJzRpBJx+1ekrEa/R6LwPTke6T6NOs9FgS8kMwueqXp5FsUKfeL3RprE5VNut6G73V ZmV9lgg6SIhdNBYoOrn9tUbM81yLfYvKHjGN7BTvBJZcPhF5i6jiQf12++8pe1zAkSLq JppGYVinb2Bji8dmnblrXrG4eS94XD3qXvZkcK04fnBJEnjOa/1+q+EOpUDXhg4/Ovpl tfgSENEiRzBPb0pqjur9LWCfLti44wbvF3vOa63s6qlLFEncW6wRuJeZwOLCSGu6ZNfZ gzu0o5zITQ9nxLgag7cI6cbp6sTpUMcHTNL6Jx9QTYsXQohkoC7Hl/TXqr0eTBquoEcC 8nBQ== X-Gm-Message-State: AOAM530xy0dar0MCV8DTpuIMbhLE+xEcaHNMyR8ln5Oqpy+CFYfRT44Y 2KBtkig8e4g++/RijvEn5pQC2XaFhrikBIn6puI= X-Google-Smtp-Source: ABdhPJwCxXIYspmpTJwS9FTqS91jLkZ8BtyROlZ3eLxeVPlb97fAOfbu7FBqhlkatdppJ0gj2gNaqe3PCY1a0OSCQmQ= X-Received: by 2002:a67:cf08:: with SMTP id y8mr749025vsl.227.1592296307304; Tue, 16 Jun 2020 01:31:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 16 Jun 2020 10:31:36 +0200 Message-ID: To: "G. P. B." Cc: Benas IML , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000c62be405a82f5f0a" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=) --000000000000c62be405a82f5f0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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). 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. 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=C3=A1t=C3=A9 --000000000000c62be405a82f5f0a--