Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110593 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 43629 invoked from network); 16 Jun 2020 15:25:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jun 2020 15:25:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6A8B61804CE for ; Tue, 16 Jun 2020 07:11:24 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (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 07:11:23 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id z206so11847840lfc.6 for ; Tue, 16 Jun 2020 07:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rushlow.dev; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eZ9IYxQO3FY6rf+U1exvHPMhhTzVhtXA0dq2vfPSiqg=; b=JCW7TWasrV042TWjQpMPfwEH6flNTc0vg65viILJfDX+sQdCXdSxRNsZn2V+D782qN nwt6PvNk1EHymzPqkNGpv9cyTyLrV2qYBOJPT7rcZ61Z3Vi9z8+rT04duD6KCPdvST6h dPxcQQcznnE/gzHhUti/cVzMCFzpFmwTfUrq2oC6kgOxU2btq/H9jKkpn6tfZRCczWrY 5HDTkL3eEcyovsGvKyXYB8BqVsD4NSmtfM8NF168d27T2x5+Ttl80B9klQwXoKpOThYn lshMHu9jthpnOsAODHqxA/OX4nE5QcRN2d8Och5TiplhZ+fEYmKdt9Cn3gFOwW42b19h x9mw== 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=eZ9IYxQO3FY6rf+U1exvHPMhhTzVhtXA0dq2vfPSiqg=; b=F1wAJsC7swv2ckzilLTvAhNH//ksTMMDKuZgAwJhN7ub+hv61uTv/ZdFL2oLRIh6tE T16zaOiWNCCL3/riFjYIN3KyYeTI0OPMv0clGPeif3NdMGMy2SuyGuFdp513sd3Y3dLn X3Ukpk9WZlbohIrUNyoNZubsTIXXhmMoJ4a2fkYUnJVbX9hCkp3GOa1VJ+jNDzp6uCPV UVNQPZSxqaZTsgvvfirSJrgQq4m2/JwBe2GOV24Ps7kNHp3T3CK7Wjbd5bHxrbQ5hqJj mEm3IMNV8S5x9G1BoEk8b5/eQKOY1f0duPh9pgAg7ilaqmlbxnoHKd92RGyunOye7SLC czgQ== X-Gm-Message-State: AOAM532FwVAhk2iGvDPVzUpv2cBovMltbxJGELuGbvyCcpF3qhPM3s4R V4Toydc0NneFKXRluqHzhrXGrizyhHNqR0eh/+8Wkg== X-Google-Smtp-Source: ABdhPJwhx346Wh0dW/18aWouhHIVjB34xfumKfn4jonRUSsrkBrP8erdH2nYr6jFDD3tzV4aA2g6+NSpmRE6Hy0SkK8= X-Received: by 2002:a19:4945:: with SMTP id l5mr1878224lfj.12.1592316681411; Tue, 16 Jun 2020 07:11:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 16 Jun 2020 10:11:20 -0400 Message-ID: To: Dan Ackroyd Cc: Benas IML , =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , "G. P. B." , PHP Internals List Content-Type: multipart/alternative; boundary="0000000000002a79f905a8341e5d" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors From: jr@rushlow.dev (Jesse Rushlow) --0000000000002a79f905a8341e5d Content-Type: text/plain; charset="UTF-8" From a PHP developer's POV - when writing a class or refactoring one. I have to catch myself all the time trying to declare ": void" on the constructor. It's mostly a habit from doing so with the other methods in the class. I lean in favor of being able to declare a void return type on a constructor, but only for the aforementioned reason. I have never ran into a use case where I've questioned what the return type is for a constructor. Although I could see newcomers to PHP / Development in general ponder that thought. Thanks, Jesse Rushlow On Tue, Jun 16, 2020 at 8:59 AM Dan Ackroyd wrote: > G.P.B. wrote: > > Seems like a no brainer and a good addition. :) > > For situations where stuff is simple, 'no brainers' are okay. > For situations where everything is horribly convoluted, 'no brainers' > are often bad. > > Benas IML wrote: > > even though no return type means mixed|void > > Not quite. > > No return type is _treated as_ 'mixed|void' in some circumstances > particularly signature checks during inheritance. That's not quite the > same as 'meaning' the same. > > > What I meant, was that since no return type means `mixed|void`, > > you can't do the following: > > I'm actually not sure exactly what you're trying to say there, but I > think pasting the text I reference whenever trying to think about LSP > might be useful... > > "PHP allows contravariance (aka type widening) for parameter types to > obey the LSP principle. A subclass may use a 'wider' aka less specific > type in place of the inherited type for a parameter." > > "PHP allows covariance (aka type narrowing) for return types to obey > the LSP principle. A subclass may use a 'narrower' aka more specific > type in place of the inherited type for a function return." > > > I am proposing to allow void return type for constructors/destructors. > > Constructors in PHP have multiple issues that are 'surprising'. I'm > not sure that fixing only a small part of how they are surprising, > improves PHP drastically. > > Also...I really wish we already had null as a usable type, as most of > the uses of void are slightly inaccurate. > > The meaning of void and null are: > > void - this function doesn't return a value > null - this function returns a value that has no information in it. > > Presumably you want to be able to specify void as the return type to > make it be easier to detect errors in code like the example you > provided. > > It seems that making a rule for whichever static analyzer you're > using, that errors on any assigning of a value from a __construct > call, would achieve that, without touching a part of PHP that is full > of edge cases. > > To be clear, I'm not sure if I am in favour or against the RFC. The > real problem is that constructors just don't fit into how we think > about normal functions is PHP, because of the magic that goes on > around them and so both void and null as return types would be a > little bit incorrect. > > cheers > Dan > Ack > > > > Some example functions using those two return types. > > function this_is_void_return(): void { > exit(0); > } > > function this_is_also_void_return(): void { > throw new Exception("no usuable return value"); > } > > function this_is_also_also_void_return(): void { > while (1) { > echo "Hello world\n"; > } > } > > function this_is_null_return(): null { > // deliberately empty. > } > > // This code is fine. > var_dump(this_is_null_return()); > > // This code is never going to execute the var_dump, which > // might indicate an error. > var_dump(this_is_void_return()); > var_dump(this_is_also_void_return()); > var_dump(this_is_also_also_void_return()); > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --0000000000002a79f905a8341e5d--