What do you think about default return values?
e.g.
function foo(): db_result = null {
}
function canLogin(): bool = false {
}
Regards
Thomas
Dmitry Stogov wrote on 20.04.2016 18:13:
> What we really miss now, is an ability to define nullable return types.
>
>
> https://wiki.php.net/rfc/nullable_return_types
>
>
> I don't care about the same notations for arguments (and everything else),
> because we already may use NULL default value.
>
> However usage of "?" for arguments also may make sense. Someone may like this,
> someone not.
>
>
> Thanks. Dmitry.
>
> ________________________________
> From: guilhermebla...@gmail.com <guilhermebla...@gmail.com>
> Sent: Wednesday, April 20, 2016 18:05
> To: Lin Yo-An
> Cc: Dmitry Stogov; Tom Worster; internals
> Subject: Re: [PHP-DEV] [RFC] Nullable Types
>
> I read the RFC and I want to highlight why I'll vote -1 on it even before it
> goes to voting.
>
> IMHO, it looks backwards to what the language is progressing. The introduction
> of nullable type hint as a separate notation than a simple type hint makes it
> *very* hard to implement typed properties, factory methods and constructor
> verifications.
>
> Dmitry is even involved in the discussion of having IS_UNDEF until constructor
> ends, then enforcing type hinting at the end of constructor to trigger
> potential invalid instance state. It created a mess in the internal structure
> by creating a 3-state value: uninitialized, absent of value (null) and
> assigned
> value. All this problem would be solved by merging null into accepted value.
> So far the proposed solution there to take a wrong assumption to assume a
> default value based on type defined (like int = 0, string = '', etc), which
> are
> all potential valid values, leading to unpredictable behavior if a develop
> misses to assign a value to that property.
>
> Sure, people will say that now PHP will require a NullPointerException, PHP is
> turning into Java, or that I don't know what I'm talking about because they
> coded for Amiga and I don't (yes, I've seen that already in this mailing
> list).
> But the fact is that keeping control of 3-state flags are hard to maintain.
>
> Constructor verifications is actually a completely different subject that
> shouldn't be considered as part of typed properties, but for final properties
> (or whoever other keyword someone think is smarter because *reasons*). It's
> bad
> to bring this already to typed properties, specially because of its runtime
> performance impact.
>
> Now let's say we move forward with nullable type hint, ignore everything what
> I
> said and move forward. Congratulations, we just created a language
> inconsistency. Example:
>
> function foo(Bar $bar = null);
>
> Why now I have 2 ways to define a nullable value? Shouldn't this be changed
> into this:
>
> function foo(?Bar $bar);
>
> But of course, changing this would be a BC break and should be left for
> *reasons*. But accepting the absence of value (null) as a valid value, it
> would
> address the language inconsistency (the current support would be kept, so no
> BC
> break), and would solve a huge mess that typed properties patch currently
> needs
> to solve. Ah, and we don't continue into this path of madness where same thing
> have 144 different ways in different areas to be defined.
>
>
> Regards,
>
> On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An
> <cornelius.h...@gmail.com<mailto:cornelius.h...@gmail.com>> wrote:
> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov
> <dmi...@zend.com<mailto:dmi...@zend.com>> wrote:
>
>> The grammar is taken from HHVM.
>> Using any other would make more mess.
>>
> I agree
>
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
