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....@gmail.com> wrote: > On Sun, Aug 7, 2016 at 9:07 AM, Davey Shafik <m...@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 >> > >
