Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92558
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <BY2PR0201MB178494E8EF85885D7AB287E6BF6D0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CAFMT4No6yFJ4r4bWGOaLZkYdpqE_YeDiEHCecq4ATBqypeUegQ@mail.gmail.com> <570F4BB4.6020709@zend.com> <57112225.6020905@thefsb.org> <BY2PR0201MB1784002A8F5F1D577220BD5BBF680@BY2PR0201MB1784.namprd02.prod.outlook.com> <57119B5E.6070205@thefsb.org> <BY2PR0201MB178497F586633AA99AD8E00ABF6B0@BY2PR0201MB1784.namprd02.prod.outlook.com> <CAKSD0w6mg5qfPZ2AexsZLppPi+hHtt9vnW2Zmfsj+A1_AMEtrg@mail.gmail.com>,<CAFp73Xsu-+XC6aVz5Yt08HntyW3NaPm+hJYsPpoxzoqEmvxN1w@mail.gmail.com><BY2PR0201MB178494E8EF85885D7AB287E6BF6D0@BY2PR0201MB1784.namprd02.prod.outlook.com>
To: guilhermeblanco@gmail.com, cornelius.howl@gmail.com, dmitry@zend.com
Cc: fsb@thefsb.org, internals@lists.php.net
Message-ID: <20160420165307.9C86E1A83D08@dd1730.kasserver.com>
Date: Wed, 20 Apr 2016 18:53:07 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] Nullable Types
From: mails@thomasbley.de ("Thomas Bley")

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: guilhermeblanco@gmail.com <guilhermeblanco@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.howl@gmail.com<mailto:cornelius.howl@gmail.com>> wrote:
> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov
> <dmitry@zend.com<mailto:dmitry@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
>