Re: [RFC] Nullable Types

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 >