Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94893
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.174 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8ZBy4OE-hg=f334e8QyL8pbKtq_AchTimRyr4ROn_vdw@mail.gmail.com>
References: <CANaX5ne1BHOQ4Q8OUPWx-=Sg43zd6L54HZ7DbVzUZniTk9hkKw@mail.gmail.com>
 <CAF+90c8ZBy4OE-hg=f334e8QyL8pbKtq_AchTimRyr4ROn_vdw@mail.gmail.com>
Date: Sun, 7 Aug 2016 01:27:18 -0700
Message-ID: <CANaX5neha+nJso4ZYf3TX-NuFV2KCD_ASn92DhWk1qiRJOXoSw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0490786880bc0539771108
Subject: Re: [PHP-DEV] Undocumented Nullable Return Behavior
From: me@daveyshafik.com (Davey Shafik)

--94eb2c0490786880bc0539771108
Content-Type: text/plain; charset=UTF-8

Nikita,

Just to confirm for explicitness-sake:

> Nullable return types work inversely to void return types. You must
return either the specified type, or an explicit null. Anything else is
either a TypeError (incorrect type [implicitly] returned), or a [compile
time] fatal error (return without value).

Is it worthwhile updating the RFC with this information and examples as it
is most likely what will be used to create documentation (if it's not been
documented already) and the spec.

I'm happy to do that, if that's desired.

- Davey

On Sun, Aug 7, 2016 at 12:58 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sun, Aug 7, 2016 at 9:07 AM, Davey Shafik <me@daveyshafik.com> wrote:
>
>> Hi internals,
>>
>> In the nullable types we do not allow implicit return null/return with no
>> value to fulfill a nullable type.
>>
>> - No return will result in a TypeError when executed
>> - Return with no value will be an actual fatal error, which I believe is
>> due to the fact it's not found at runtime, should be a TypeError or
>> ParseError if possible?
>>
>
> It's a compile time error. Compile time errors are currently fatal errors
> for technical reasons.
>
>
>> - Return explicit null is fine (as expected)
>>
>> See: https://3v4l.org/h6IYF
>>
>> I believe the first two are contrary to PHP's "null is always returned if
>> nothing else is".
>>
>> OTOH, it makes sense as it's the entire reasoning behind return void vs
>> return null.
>>
>
> Indeed. The current behavior is consistent with the (explicit decision
> from) the void RFC.
>
> Additionally, the current behavior is consistent with the behavior of the
> implementation at the time the RFC was voted, with the only difference that
> I have made this a compile-time error after the fact (because I think if we
> know that something will always result in a runtime error, we should try to
> detect it at compile-time already, and because the void error is detected
> at compile-time as well).
>
> Nikita
>
>
>> This behavior is completely undocumented in the RFC.
>>
>> It's definitely something we should make an explicit decision on for the
>> language spec if nothing else.
>>
>> We should also make any decisions on this prior to beta3 in < 2 weeks.
>>
>> Thoughts?
>>
>> - Davey
>>
>
>

--94eb2c0490786880bc0539771108--