Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110595
MIME-Version: 1.0
References: <CANeKSiR18yf7modMbr5ZB5XSe6a3MKwurdZeq9L2g3X=OpUYSA@mail.gmail.com>
 <CAFPFaMLx4XXmzCbfm-O-qoKxS9GA5FsN44H9vgHAzJ09L66mtg@mail.gmail.com>
 <CAH5C8xVH2RdPStkW8DsEYBCANT2KrE2_QKUFQy4+ZQRg4-1q3w@mail.gmail.com>
 <CANeKSiR=cD=J1eot5SmXWVqq-PC6mPjBg9im26WZBMM1hwGj1A@mail.gmail.com> <CA+kxMuTuWiAMgBr=1o_O1oAOi2cwLBBCXeAbFpNGNk4SMcHYpQ@mail.gmail.com>
In-Reply-To: <CA+kxMuTuWiAMgBr=1o_O1oAOi2cwLBBCXeAbFpNGNk4SMcHYpQ@mail.gmail.com>
Date: Tue, 16 Jun 2020 17:19:21 +0300
Message-ID: <CANeKSiTiyv7=CpUvKNzGmk5dZO_9WTGEpbTfYcATM1_J9U75yw@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	"G. P. B." <george.banyard@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000846d6505a8343bd0"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000846d6505a8343bd0
Content-Type: text/plain; charset="UTF-8"

Hey Dan,

Thanks for your reply.

> No return type is _treated as_ 'mixed|void' in some circumstances
Could you elaborate? No return type DOES mean `mixed|void`, could you give
any pointers as to where that is different?

> I'm actually not sure exactly what you're trying to say there
I meant something like this:
```
<?php
class Test {
    public function __construct() {}
}

class Test2 extends Test {
    /* this is legal */
    public function __construct(): void {}
}

class Test3 extends Test {
    /*
     * this is illegal, even though no
     * return type means mixed|void
     */
    public function __construct(): mixed {}
}

class Test4 extends Test2 {
    /*
     * this is legal, even though we are
     * widening void type to mixed|void
     * but LSP checks don't apply to
     * constructors and destructors
     */
    public function __construct() {}
}
```

This RFC's goal isn't to fix constructor issues. My goal is to allow to
(for those that want to) add an optional void return type to
constructors/destructors (for example to have complete consistency with
other methods).

On Tue, Jun 16, 2020, 3:59 PM Dan Ackroyd <Danack@basereality.com> 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());
>

--000000000000846d6505a8343bd0--