Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110588
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>
In-Reply-To: <CANeKSiR=cD=J1eot5SmXWVqq-PC6mPjBg9im26WZBMM1hwGj1A@mail.gmail.com>
Date: Tue, 16 Jun 2020 13:59:26 +0100
Message-ID: <CA+kxMuTuWiAMgBr=1o_O1oAOi2cwLBBCXeAbFpNGNk4SMcHYpQ@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.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: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
From: Danack@basereality.com (Dan Ackroyd)

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());