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&recipient=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D), the best free email app for work On Mar 11 2021, at 10:51 am, Hamza Ahmad <office.hamzaah...@gmail.com> 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 <rowan.coll...@gmail.com> > 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: > ><?php > >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 >
