Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110596
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> <CAES=RMucp5sJT-fH+Nsk47W8R2L00xKu-YUzP=Y8ez2-7jjNMQ@mail.gmail.com>
In-Reply-To: <CAES=RMucp5sJT-fH+Nsk47W8R2L00xKu-YUzP=Y8ez2-7jjNMQ@mail.gmail.com>
Date: Tue, 16 Jun 2020 17:25:06 +0300
Message-ID: <CANeKSiRouE6pzpjyHoVbJtk0UV-rmDcGvd1aEOiXRiztDTrhxA@mail.gmail.com>
To: Jesse Rushlow <jr@rushlow.dev>
Cc: Dan Ackroyd <Danack@basereality.com>, =?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="0000000000001b652805a83450f1"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
From: benas.molis.iml@gmail.com (Benas IML)

--0000000000001b652805a83450f1
Content-Type: text/plain; charset="UTF-8"

Exactly :)

Personally, I have numerous times caught myself declaring constructors `:
void` too. I would love to have everything consistent and all methods to
have a return type.

Although, I do understand that not everybody agrees with me and that's why
this RFC isn't planning to ever force people to use `void` return type.

As I have said before: some might use it, some might not, but both cases
are valid and allowed :)

Best regards,
Benas

On Tue, Jun 16, 2020, 5:11 PM Jesse Rushlow <jr@rushlow.dev> wrote:

> 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 <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());
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

--0000000000001b652805a83450f1--