Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113490
To: "'Mike Schinkel'" <mike@newclarity.net>
Cc: <internals@lists.php.net>
References: <01fa01d71627$edb078a0$c91169e0$@gmail.com> <5ACB32D5-C7EC-4332-ABB1-B519CEDCC019@newclarity.net>
In-Reply-To: <5ACB32D5-C7EC-4332-ABB1-B519CEDCC019@newclarity.net>
Date: Fri, 12 Mar 2021 07:46:54 +0500
Message-ID: <002301d716e9$f971ba10$ec552e30$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEkxYUdW5hh6aEiWom8mpkeVucJUAGYmSYJq9eAZ0A=
Content-Language: en-us
Subject: RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature
From: office.hamzaahmad@gmail.com ("Hamza Ahmad")

Thank you for providing me with the feedback, experts! Initially, I =
wanted empty returns in void functions. When I prepared the request, I =
included the other solutions that I felt important and worth adding. Is =
it not possible to go with empty returns in void functions? I agree that =
the code can be adjusted to fit the current environment; still, people =
avoid writing lengthy blocks of code. An empty return with defaults will =
help them with the code that is easier to maintain.
I clarified my stance on first email in a response to a respectable =
member of the list. I do not know why that email is not appearing on =
externals. I will make sure that next time I post an external URL that =
contains the changelog and do not clutter the mailing list.
I am again thankful to you all!
Best
Hamza Ahmad

-----Original Message-----
From: Mike Schinkel <mike@newclarity.net>=20
Sent: Thursday, March 11, 2021 10:05 PM
To: office.hamzaahmad@gmail.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement =
According to the Function Signature

> On Mar 10, 2021, at 10:37 PM, office.hamzaahmad@gmail.com wrote:
>=20
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also=20
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has=20
> created another problem for those that use 'return' to end the=20
> execution of a function or method call.

Welcome.

> There are mainly two usages of 'return'. First ends the execution of=20
> the remaining statements. Second returns a value. The return type=20
> hints aids with the second usage and ignores the former facility. In=20
> other words, if one wants to avoid large code blocks i.e. the=20
> conditional blocks, it can write like following.
>=20
> <?php
> function foo()
> {
> 	If (true /*condition1*/)
> 		return;
>=20
> 	if (!false /*condition2*/)
> 		return;
>=20
> 	/*the remaining part of a function*/
> };
> ?>

However, I agree with Larry.  This feels either like a code smell and/or =
could be handled with a variable.

This pattern can be very frustrating in other people's code when I =
either need to debug it or might want to debug it to learn the code =
because it requires setting IDE breakpoints in many places to be sure =
that catch an exit. And invariably I miss breakpointing a return when =
debugging and am left wondering what happened.  See =
https://youtrack.jetbrains.com/issue/WI-40862

As an alternate I developed a technique using `do{...} while(...)` in a =
novel way that I wish PHP supported more cleanly, but it nonetheless =
works great.=20

The technique uses `do {...} while(false)` to create a block that break =
can exit early on guard clauses, for example (btw, I would return `null` =
instead of `'unknown'` and enclose the breaks in braces for the =
`if(...)` statement, but I wanted my example to be equivalent to yours):

<?php
function foo() {

    $value =3D 'unknown';           // Set the default return value up =
here
   =20
    do {

	if (/*condition1*/)   =20
		break;			// <=3D=3D see, no need for a value here

	if (/*condition2*/)
		break;			// <=3D=3D or here!
       =20
	/*the remaining part of a function that sets $value */

    } while (false);
   =20
    return $value;			// The only return in this function. Debugging =
nirvana.

}

Maybe you can use this approach instead to allow you to not have to =
annotate each early exit with a return value?

-Mike

P.S. Ideally PHP would support (something like) a naked `do{...}` =
=E2=80=94 or a naked `try{...}` that supports `break` =E2=80=94 though I =
have not tried to convince the list because status quo has the inertia =
here. But I mention this in hopes others see value in it and would help =
champion the idea. #fwiw


> The above function returns null if conditions are met. Otherwise, it=20
> returns no value. It was okay when there was no concept of return type =

> hints. When return types have been introduced, the behaviour needs to =
be evolved, too.
> What if the return type was set 'int|float' in the above example? The=20
> compiler would give following error:
> Fatal error: A function with return type must return a value....=20
> Similarly, a function with ': void' signature produceed that a=20
> function may not return a value.
> To resolve such a problem, I request to honour the function signature=20
> when you evaluate return statements. Instead of looking for no =
'return'
> statements in ': void' functions, verify whether a function specifies=20
> a return value. If the function returns a type other than the types=20
> declared in the signature, it may produce wrong type error. If a=20
> function with void returns a value i.e. contains a non-empty return=20
> (return;) statement, the compiler may throw an error stating that a=20
> function with void signature must not return a value.
> Likewise, 'return' may return an empty array if the return type was=20
> set to array; the similar case applies to string, int, float, object=20
> etcetera. In the case of ': void' signature, 'return' only ends the=20
> execution and returns no value.
> PHP also allows to specify only returning 'false' from a function=20
> call. What if you extend this functionality and allow specifying=20
> literals including null? If nulls are also allowed, the backword=20
> behaviour could be impleamented. For example:
> public function foo() : string| null;
>=20
> Consider the following example for literals.
> <?php
> function get_nationality_string(int $country_code) : string | =
"unknown"
> {
> 	return;
> };
> ?>
>=20
> I am positive that you will consider my request and provide me with=20
> the feedback in case of any inconsistency in my argument. I wish you=20
> best of luck for the on-going work for the PHP 8.1.
> Best Regards
> Hamza Ahmad
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,=20
> visit: https://www.php.net/unsub.php
>=20