RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[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  
Sent: Thursday, March 11, 2021 10:05 PM
To: office.hamzaah...@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.hamzaah...@gmail.com wrote:
> 
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also 
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has 
> created another problem for those that use 'return' to end the 
> execution of a function or method call.

Welcome.

> There are mainly two usages of 'return'. First ends the execution of 
> the remaining statements. Second returns a value. The return type 
> hints aids with the second usage and ignores the former facility. In 
> other words, if one wants to avoid large code blocks i.e. the 
> conditional blocks, it can write like following.
> 
>  function foo()
> {
>   If (true /*condition1*/)
>   return;
> 
>   if (!false /*condition2*/)
>   return;
> 
>   /*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. 

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):

 The above function returns null if conditions are met. Otherwise, it 
> 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 
> compiler would give following error:
> Fatal error: A function with return type must return a value 
> Similarly, a function with ': void' signature produceed that a 
> function may not return a value.
> To resolve such a problem, I request to honour the function signature 
> when you evaluate return statements. Instead of looking for no 'return'
> statements in ': void' functions, verify whether a function specifies 
> a return value. If the function returns a type other than the types 
> declared in the signature, it may produce wrong type error. If a 
> function with void returns a value i.e. contains a non-empty return 
> (return;) statement, the compiler may throw an error stating that a 
> function with void signature must not return a value.
> Likewise, 'return' may return an empty array if the return type was 
> set to array; the similar case applies to string, int, float, object 
> etcetera. In the case of ': void' signature, 'return' only ends the 
> execution and returns no value.
> PHP also allows to specify only returning 'false' from a function 
> call. What if you extend this functionality and allow specifying 
> literals including null? If nulls are also allowed, the backword 
> behaviour could be impleamented. For example:
> public function foo() : string| null;
> 
> Consider the following example for literals.
>  function get_nationality_string(int $country_code) : string | "unknown"
> {
>   return;
> };
> ?>
> 
> I am positive that you will consider my request and provide me with 
> the feedback in case of any inconsistency in my argument. I wish you 
> best of luck for the on-going work for the PHP 8.1.
> Best Regards
> Hamza Ahmad
> 
> --
> PHP Internals - PHP Runtime Development Mailing 

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Mike Schinkel]

> On Mar 10, 2021, at 10:37 PM, office.hamzaah...@gmail.com wrote:
> 
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has created
> another problem for those that use 'return' to end the execution of a
> function or method call.

Welcome.

> There are mainly two usages of 'return'. First ends the execution of the
> remaining statements. Second returns a value. The return type hints aids
> with the second usage and ignores the former facility. In other words, if
> one wants to avoid large code blocks i.e. the conditional blocks, it can
> write like following.
> 
>  function foo()
> {
>   If (true /*condition1*/)
>   return;
> 
>   if (!false /*condition2*/)
>   return;
> 
>   /*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. 

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):

 The above function returns null if conditions are met. Otherwise, it 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
> compiler would give following error:
> Fatal error: A function with return type must return a value Similarly,
> a function with ': void' signature produceed that a function may not return
> a value.
> To resolve such a problem, I request to honour the function signature when
> you evaluate return statements. Instead of looking for no 'return'
> statements in ': void' functions, verify whether a function specifies a
> return value. If the function returns a type other than the types declared
> in the signature, it may produce wrong type error. If a function with void
> returns a value i.e. contains a non-empty return (return;) statement, the
> compiler may throw an error stating that a function with void signature must
> not return a value.
> Likewise, 'return' may return an empty array if the return type was set to
> array; the similar case applies to string, int, float, object etcetera. In
> the case of ': void' signature, 'return' only ends the execution and returns
> no value.
> PHP also allows to specify only returning 'false' from a function call. What
> if you extend this functionality and allow specifying literals including
> null? If nulls are also allowed, the backword behaviour could be
> impleamented. For example:
> public function foo() : string| null;
> 
> Consider the following example for literals.
>  function get_nationality_string(int $country_code) : string | "unknown"
> {
>   return;
> };
> ?>
> 
> I am positive that you will consider my request and provide me with the
> feedback in case of any inconsistency in my argument. I wish you best of
> luck for the on-going work for the PHP 8.1.
> Best Regards
> Hamza Ahmad
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Chase Peeler]

On Thu, Mar 11, 2021 at 10:37 AM Larry Garfield 
wrote:

> On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> > Hi Victor,
> >
> > It does not contradict because it does not cover two different aspects.
> > First, return types specify the types of to be returned values. Second,
> > this request proposes a shorthand technique to avoid writing a single
> > line code multiple times. Third, it is similar to default argument
> > values that are also typed.
> >
> > Cheers!
>
> Greetings.  First, please don't top post.  This is a bottom-posting list.
>
> As to your proposal, it's a bit hard to follow because it sounds like
> you're suggesting an implicit "return of nothing" built on union types,
> when based on your follow ups what I think you're suggesting is something
> more like this:
>
> function foo(int $bar = 4): int = 0 {
>   if (is_even($bar)) {
> return; // Implicitly returns 0
>   }
>   return $bar * 2;
> }
>
> That is, allowing a default return value.  Union types aren't part of the
> picture.
>
> I can see how you got to the idea, but honestly I am not a fan.
> Primarily... I've never run into the situation you describe where multiple
> early-returns would have the same value.  Perhaps it's just because in
> those cases I end up combining the conditionals with an ||, but I don't see
> the problem you describe.  Different code paths should result in different
> results, or else why are they different code paths?
>
> So, code that's doing that I'd be suspicious of to begin with.
>
>
There are times, for the sake of readability, where I might break things up
into multiple if statements instead of combining them with an OR.

Sometimes you need to do additional work between conditionals as well:

if($id == 0){
   return null;
}

$record = $db->get($id);

if(empty($record)){
  return null;
}

Regardless, I think your solution below works just fine.


> Even if you did end up in such a situation, since you're dealing with a
> static value, setting the default internally within the function is trivial:
>
> function foo(int $bar = 4): int {
>   $default = 0;
>   if (is_even($bar)) {
> return $default;
>   }
>   return $bar * 2;
> }
>
> So basically, in the few cases where this isn't a code smell, it's
> unnecessary.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Larry Garfield]

On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> Hi Victor,
> 
> It does not contradict because it does not cover two different aspects. 
> First, return types specify the types of to be returned values. Second, 
> this request proposes a shorthand technique to avoid writing a single 
> line code multiple times. Third, it is similar to default argument 
> values that are also typed.
> 
> Cheers!

Greetings.  First, please don't top post.  This is a bottom-posting list.

As to your proposal, it's a bit hard to follow because it sounds like you're 
suggesting an implicit "return of nothing" built on union types, when based on 
your follow ups what I think you're suggesting is something more like this:

function foo(int $bar = 4): int = 0 {
  if (is_even($bar)) {
return; // Implicitly returns 0
  }
  return $bar * 2;
}

That is, allowing a default return value.  Union types aren't part of the 
picture.

I can see how you got to the idea, but honestly I am not a fan.  Primarily... 
I've never run into the situation you describe where multiple early-returns 
would have the same value.  Perhaps it's just because in those cases I end up 
combining the conditionals with an ||, but I don't see the problem you 
describe.  Different code paths should result in different results, or else why 
are they different code paths?

So, code that's doing that I'd be suspicious of to begin with.

Even if you did end up in such a situation, since you're dealing with a static 
value, setting the default internally within the function is trivial:

function foo(int $bar = 4): int {
  $default = 0;
  if (is_even($bar)) {
return $default;
  }
  return $bar * 2;
}

So basically, in the few cases where this isn't a code smell, it's unnecessary.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Hi Victor,

It does not contradict because it does not cover two different aspects. First, 
return types specify the types of to be returned values. Second, this request 
proposes a shorthand technique to avoid writing a single line code multiple 
times. Third, it is similar to default argument values that are also typed.

Cheers!

 

From: Victor Bolshov  
Sent: Thursday, March 11, 2021 3:00 PM
To: Hamza Ahmad 
Cc: Rowan Tommins ; internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

 

IMO this feature would contradict with the Single Responsibility Principle. 
Type hints are for type hinting, not for value hinting. Cheers.

 

Sent from Mailspring 

 , the best free email app for work

On Mar 11 2021, at 10:51 am, Hamza Ahmad  wrote:

Hi Rowan,

Thanks for the response. Luckily, you razed the question that I thought about 
after posting the first request.

My idea develops on respecting both return type hints and union types. The 
current implementation of empty return does not respect the function signature. 
As I have mentioned in the first message that empty return returns null 
regardless of the return type set, I propose that an empty return may return 
the defaults of types i.e. an empty string if the type is string, an empty 
array if the type is array, zero if the type is int etcetera. I have also noted 
that in a void typed function, an empty return may return nothing and just end 
the execution.

The current implementation of empty return is only favourable for mixed type. 
In other words, when the return type is mixed, an empty return may return null. 
Otherwise, it should respect the declared return type.

After the release of union types, there emerges a question regarding the 
selection of default return value. To solve this problem, the type on the very 
right side will be used.

Now, I come to your question, Rowan. As of today, only false and null literals 
are supported. If both assist in error handling, why does empty return always 
returns null?

I tested this code on shell.

var_dump($a=(function():string|false{return;})());

It produced:

Fatal error: A function with return type must return a value in php shell code 
on line 1.

Here comes the inconsistency. To resolve the problem, I suggest to respect the 
literals first. If literals are not found, respect the first type on the right 
side.

Moreover, only two standalone literals, false and null, will be supported. 
Otherwise, the literal should be one of the types specified. If multiple 
literals are specified, it will throw an error of multiple literals. The 
literal can be a simple literal, such as, "unknown" 0, and a constant 
expression, like self :: MSG_UNKNOWN. It will help maintain the multi-language 
scripts.

I hope I have been able to make my stance clear.

Best

Hamza Ahmad

 

-Original Message-

From: Rowan Tommins 

Sent: Thursday, March 11, 2021 1:45 PM

To: internals@lists.php.net

Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

 

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:

>function get_nationality_string(int $country_code) : string | "unknown"

>{

> return;

>};

 

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

 

My main concerns are with the syntax:

 

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.

- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

 

Perhaps the default return value would need to be specified separately from the 
return type somehow?

 

Regards,

Hi Hamza,

 

Welcome to the list, and thanks for sharing this idea.

 

--

Rowan Tommins

[IMSoP]

 

--

PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
https://www.php.net/unsub.php

 

--

PHP Internals - PHP Runtime Development Mailing List

To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Victor Bolshov]

IMO this feature would contradict with the Single Responsibility Principle. 
Type hints are for type hinting, not for value hinting. Cheers.

Sent from Mailspring 
(https://link.getmailspring.com/link/4d67851f-de69-45d9-9db1-54b16845e...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D),
 the best free email app for work
On Mar 11 2021, at 10:51 am, Hamza Ahmad  wrote:
> Hi Rowan,
> Thanks for the response. Luckily, you razed the question that I thought about 
> after posting the first request.
> My idea develops on respecting both return type hints and union types. The 
> current implementation of empty return does not respect the function 
> signature. As I have mentioned in the first message that empty return returns 
> null regardless of the return type set, I propose that an empty return may 
> return the defaults of types i.e. an empty string if the type is string, an 
> empty array if the type is array, zero if the type is int etcetera. I have 
> also noted that in a void typed function, an empty return may return nothing 
> and just end the execution.
> The current implementation of empty return is only favourable for mixed type. 
> In other words, when the return type is mixed, an empty return may return 
> null. Otherwise, it should respect the declared return type.
> After the release of union types, there emerges a question regarding the 
> selection of default return value. To solve this problem, the type on the 
> very right side will be used.
> Now, I come to your question, Rowan. As of today, only false and null 
> literals are supported. If both assist in error handling, why does empty 
> return always returns null?
> I tested this code on shell.
> var_dump($a=(function():string|false{return;})());
> It produced:
> Fatal error: A function with return type must return a value in php shell 
> code on line 1.
> Here comes the inconsistency. To resolve the problem, I suggest to respect 
> the literals first. If literals are not found, respect the first type on the 
> right side.
> Moreover, only two standalone literals, false and null, will be supported. 
> Otherwise, the literal should be one of the types specified. If multiple 
> literals are specified, it will throw an error of multiple literals. The 
> literal can be a simple literal, such as, "unknown" 0, and a constant 
> expression, like self :: MSG_UNKNOWN. It will help maintain the 
> multi-language scripts.
> I hope I have been able to make my stance clear.
> Best
> Hamza Ahmad
>
> -Original Message-
> From: Rowan Tommins 
> Sent: Thursday, March 11, 2021 1:45 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement 
> According to the Function Signature
>
> On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
> > >function get_nationality_string(int $country_code) : string | "unknown"
> >{
> > return;
> >};
>
> If I understand you correctly, your idea is that the "return;" here would be 
> treated automatically as "return 'unknown';" I think that's an interesting 
> idea, although I can't immediately think of a situation where I'd use it.
> My main concerns are with the syntax:
> - Firstly, specific literals aren't currently allowed in return types, and 
> allowing them would have other implications. Three exception is "false", 
> which is allowed because of its common use as an error code, including in 
> many internal functions.
> - Secondly, it could be ambiguous which is intended to be the default value, 
> if the return type was something like int|"yes"|"no"
>
> Perhaps the default return value would need to be specified separately from 
> the return type somehow?
> Regards,
> Hi Hamza,
>
> Welcome to the list, and thanks for sharing this idea.
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
> https://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Hi Rowan,
Thanks for the response. Luckily, you razed the question that I thought about 
after posting the first request.
My idea develops on respecting both return type hints and union types. The 
current implementation of empty return does not respect the function signature. 
As I have mentioned in the first message that empty return returns null 
regardless of the return type set, I propose that an empty return may return 
the defaults of types i.e. an empty string if the type is string, an empty 
array if the type is array, zero if the type is int etcetera. I have also noted 
that in a void typed function, an empty return may return nothing and just end 
the execution.
The current implementation of empty return is only favourable for mixed type. 
In other words, when the return type is mixed, an empty return may return null. 
Otherwise, it should respect the declared return type.
After the release of union types, there emerges a question regarding the 
selection of default return value. To solve this problem, the type on the very 
right side will be used.
Now, I come to your question, Rowan. As of today, only false and null literals 
are supported. If both assist in error handling, why does empty return always 
returns null?
I tested this code on shell.
var_dump($a=(function():string|false{return;})());
It produced:
Fatal error: A function with return type must return a value in php shell code 
on line 1.
Here comes the inconsistency. To resolve the problem, I suggest to respect the 
literals first. If literals are not found, respect the first type on the right 
side.
Moreover, only two standalone literals, false and null,  will be supported. 
Otherwise, the literal should be one of the types specified. If multiple 
literals are specified, it will throw an error of multiple literals. The 
literal can be a simple literal, such as, "unknown" 0, and a constant 
expression, like self :: MSG_UNKNOWN. It will help maintain the multi-language 
scripts.
I hope I have been able to make my stance clear.
Best
Hamza Ahmad

-Original Message-
From: Rowan Tommins  
Sent: Thursday, March 11, 2021 1:45 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
>function get_nationality_string(int $country_code) : string | "unknown"
>{
>   return;
>};

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

My main concerns are with the syntax:

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.
- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

Perhaps the default return value would need to be specified separately from the 
return type somehow?

Regards,
Hi Hamza,

Welcome to the list, and thanks for sharing this idea.

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Rowan Tommins]

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
>function get_nationality_string(int $country_code) : string | "unknown"
>{
>   return;
>};

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

My main concerns are with the syntax:

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.
- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

Perhaps the default return value would need to be specified separately from the 
return type somehow?

Regards,
Hi Hamza,

Welcome to the list, and thanks for sharing this idea.

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php