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-54B16845E340@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.hamzaahmad@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.collins@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.hamzaahmad@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
>