<div class="article">
  <div class="body">
    <div class="articleListItem">
      <h1><a name="php_internals_news_episode_99_allow_null_and_false_as_standalone_types"/>PHP Internals News: Episode 99: Allow Null and False as Standalone Types</h1>
      <dl class="head"/>
      <div class="articleMetaData">
        <div class="location"> London, UK</div>
        <div class="date">Thursday, March 10th 2022, 09:04 GMT</div>
      </div>
      <p>In this episode of "PHP Internals News" I talk with George Peter Banyard (<a href="https://gpb.moe">Website</a>, <a href="https://twitter.com/Girgias">Twitter</a>, <a href="https://github.com/Girgias">GitHub</a>, <a href="https://gitlab.com/Girgias">GitLab</a>) about the "Allow Null and False as Standalone Types" RFC that he has proposed.</p>
      <p>The RSS feed for this podcast is <a href="https://derickrethans.nl/feed-phpinternalsnews.xml">https://derickrethans.nl/feed-phpinternalsnews.xml</a>, you can <a href="https://derickrethans.nl/media/pin-099.mp3">download</a> this episode's MP3 file, and it's available on <a href="https://open.spotify.com/show/1Qcd282SDWGF3FSVuG6kuB">Spotify</a> and <a href="https://itunes.apple.com/gb/podcast/php-internals-news/id1455782198?mt=2">iTunes</a>. There is a dedicated website: <a href="https://phpinternals.news">https://phpinternals.news</a></p>
      <div class="articleSubSection">
        <h2><a name="transcript"/>Transcript</h2>
        <dl>
          <dt>Derick Rethans  0:15</dt>
          <dd>
            <p>Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explain the latest developments in the PHP language. This is episode 99. Today I'm talking with George Peter Banyard, about the Allow null and false at standalone types RFC that he's proposing. Hello, George Peter, would you please introduce yourself?</p>
          </dd>
          <dt>George Peter Banyard  0:36</dt>
          <dd>
            <p>Hello, my name is George Peter Banyard. I work on the PHP language, and I'm an Imperial student in maths in my free time.</p>
          </dd>
          <dt>Derick Rethans  0:44</dt>
          <dd>
            <p>Are you're trying to say you're a student in your free time or contribute to PHP in your free time?</p>
          </dd>
          <dt>George Peter Banyard  0:49</dt>
          <dd>
            <p>I feel like at this time, it's like, both are true at the same time.</p>
          </dd>
          <dt>Derick Rethans  0:53</dt>
          <dd>
            <p>Let's hop into this RFC. It is titled allow null and false as standalone types. What is the problem that it is trying to solve?</p>
          </dd>
          <dt>George Peter Banyard  1:02</dt>
          <dd>
            <p>This is the second iteration of this RFC. So the first one was to just allow null initially, and null is the unit type In type theory parlance of PHP, ie the type which only has one value. So null is a type and a value. And the main issue is that when for leads more with like inhabitants, and like the Liskov substitution principle. If you have like a method, like the parent method, which can be told like either null or an object, and your implementation in a child class always returns null, for various reasons, maybe because it doesn't support this feature, or whatever is out, or... If your child method only returns null, currently, you can't document, that you can't type this properly, you can document it in a doc comment or something like that. But due to how PHP type handling works, you need to specify at least like another type with null in the union. Basically resort to always saying like mimicking the parent signature, when you could be more specific. This was the main use case I initially went into.</p>
          </dd>
          <dt>Derick Rethans  2:08</dt>
          <dd>
            <p>If I understand correctly, you can't just have an inherited method that has hinted as to just return null?</p>
          </dd>
          <dt>George Peter Banyard  2:14</dt>
          <dd>
            <p>Exactly. If you always return null, maybe because you always work or something like that, then you must still declare the return type as like null or exception, which is not a concrete because you say what, like why never fail. And like static analysers, if they can figure it out that you're using a child class, they can't maybe like do some assumptions or work further down that like what you're doing is redundant or things like that. So that's one of the main reasons I initially went with it. And I didn't add false initially, because it was like, well, false, it's not really a type properly. It's, it's what's called a value type. False is one value from the Boolean type. And I was like, Well, okay, we're just going to limit it to like, being the type theory purist, limited to proper types, where null is a proper type, although it's a bit sometimes misunderstood, I feel in the PHP community at large. And then people were like, well, if we add null, then by the only type-ish thing, which you can use in a type declaration, or whatever, which can't be used in a return type on its own, is false. And it's just weird. So why not add it in full. So that was the second thing as to why I added it. Some of PHP internal's functions being terribly designed because they were designed back in the early noughties, return null on success and false on failure, which you can't probably type at the moment. Currently, we need to type them as like Boolean or null, but true can never be returned in this case. And there are some other some other people have reached out to me it's like, well, yeah, but I always return false in this case. Or I also return always true in this case, although true, we have this weird asymmetry that we have false as a value type and not true.</p>
          </dd>
          <dt>Derick Rethans  3:49</dt>
          <dd>
            <p>What was the reason for having false but not true?</p>
          </dd>
          <dt>George Peter Banyard  3:53</dt>
          <dd>
            <p>When the union type RFC got discussed and passed for PHP 8.0, false was added, because a lot of traditional behaviour of PHP internal functions, was to return false on failure, instead of the technically more correct thing would be to return null. Because loads of functions return a false on failure, and saying that like in returns, these types, or a Boolean would be basically lying because you could never have true, false was included in it. With the restrictions that you can only use false as the complement with other types. So you need to do for example, array, or false, you couldn't just use false.</p>
          </dd>
          <dt>Derick Rethans  4:37</dt>
          <dd>
            <p>Would it also mean that you can define a return type of a method that inherited a method that returns a bool, as false?</p>
          </dd>
          <dt>George Peter Banyard  4:48</dt>
          <dd>
            <p>Yes, that would be now possible with the amended proposal. Yeah, which goes back to this weird a symmetry, we're probably. Adding true to make a complete would be a future RFC to do.</p>
          </dd>
          <dt>Derick Rethans  5:00</dt>
          <dd>
            <p>Now, we've talked about return types. But I guess the reverse applies to arguments?</p>
          </dd>
          <dt>George Peter Banyard  5:06</dt>
          <dd>
            <p>Arguments and property types also would, would be allowed to, like declare themselves as like null or false. The usefulness here is way more limited. Because if you declare an argument to be of type null, then basically you can only ever pass a null to it. And then therefore, the type doesn't do anything.</p>
          </dd>
          <dt>Derick Rethans  5:26</dt>
          <dd>
            <p>But in an inherited method, you could then widen it.</p>
          </dd>
          <dt>George Peter Banyard  5:31</dt>
          <dd>
            <p>Yes, exactly. You could always say: Well, this argument exists, it's always null. If you extend like your class or message, then you can add other types. But in theory, you can already do that by adding like an argument at the end of the message, because that's LSP compliant. The case for, and properties of those, because they are typing, they're in like their beads. Kind of debatable why you would do that. But it's just that like, well, if you accept types at one point, just restricting them like somewhere else gets very weird. At this point is more like look at the human review, or like use static analysis for the analyser to tell you like this argument is redundant and just remove it or this property doesn't make any sense. Because if it can only ever be null, why does it even exist in the first place?</p>
          </dd>
          <dt>Derick Rethans  6:13</dt>
          <dd>
            <p>Right now, you can already use false in union types, but why not with null or false?</p>
          </dd>
          <dt>George Peter Banyard  6:19</dt>
          <dd>
            <p>That goes back to the when a union type RFC got introduced. Null got added as a keyword. Before you could only use the question mark, before a type to make the type nullable. If you have a more complex union type, to not use the question mark in front of it. Therefore, the null keyword got added as a proper type. And because the logic was, Well, you shouldn't ever be able to return just null. Because then that function is kind of equivalent to void. Because of that, it was said that like, Well, okay, null and false basically have like kind of the same status is that like, if you just want to use null on its own, you're doing something kind of weird. And if you're returning more than false, like that signature is very strange. I think when that was discussed, nobody knew initially that an actual PHP function within one of the extensions, like in core had such a weird signature. Which mainly, we just started discovering that after this got, like accepted and we could like actually start properly typing the internal functions, and then you discover these weird edge cases where sounds like, that's a bit strange, can't properly document it. We just need to make like a note on the PHP documentation side. And like the type signature kind of lies to you. PHP's type hierarchy is a bit strange, void kind of lives on its own. So if the function is marked as void, it must always like any child inheritance, or whatever needs to be void. And when you type return in the function body, you need to always use return with like a semicolon afterwards, you can't even return null. Although, under the hood, PHP will always return a value when you call a function, even if the function is void, which will be null.</p>
          </dd>
          <dt>Derick Rethans  7:58</dt>
          <dd>
            <p>The RFC also talks about question mark null, what is that supposed to be? Is that null or null?</p>
          </dd>
          <dt>George Peter Banyard  8:03</dt>
          <dd>
            <p>PHP has this limited type redundancy checks at compile time. It will basically check if you're duplicating types. So if you write for example, int or int, even if it's capitalized differently, PHP was like, okay, just specifying twice the same type in this union. This is redundant. And then it will throw a compile error, we're basically saying, maybe you're just doing a mistake, maybe you meant something else. In the same vein, basically the question mark, gets like, translated into like, any seeing pipe null. And so if you write null with a question mark in front of it, it's just saying like, well, you're doing null or null, which is basically redundant. Therefore, you'll get like a compile time error telling you like.</p>
          </dd>
          <dt>Derick Rethans  8:41</dt>
          <dd>
            <p>That seems sensible to me. What's been the feedback so far?</p>
          </dd>
          <dt>George Peter Banyard  8:45</dt>
          <dd>
            <p>The most feedback, I think I've got it when I first proposed it in October. And at the time, it was like, Yeah, this is useful. And it's kind of needed because well, having always more type expressiveness is I think, good in general. But the main feedback at the time was like, Well, why not include false? The other feedback I got was basically, well, for consistency, what shouldn't you also add true? Yes, I do agree with this. I frankly, find it very strange that we landed in this situation where we only have one of these value types, either true and false, or none of them would make more sense to me. But that's expanding the scope. And it's kind of not this is not really concerned with this specific detail. Probably next, another RFC to do, for either myself or somebody else. It's just like propose true as a value type.</p>
          </dd>
          <dt>Derick Rethans  9:33</dt>
          <dd>
            <p>Is the implementation of this RFC complicated?</p>
          </dd>
          <dt>George Peter Banyard  9:36</dt>
          <dd>
            <p>It's very simple. It basically removes checks, because currently in the compile step, which checks for like type signatures, it needs to check that like, Well, are you declaring false or are you declaring null, and these checks get removed, so it makes the code a bit more streamlined. Oh, there's one change in reflection. For backwards compatibility reason, because of the fact of the question mark, any union type which is composed of a only two types, where one of them is null,will get converted in reflection to use the question mark notation, which is kind of a bit weird because it then gets converted into like a name type instead of a union type in reflection. But that's there, because of backwards compatibility reasons. I am breaking this into the more sensible reflection type. If you have a type of null and false, then you'll get a reflection union type instead of a named. From my understanding from reading the reflection code, the intention was always probably in PHP 9, to remove this distinction. So if you get a named type, it's only a single type instead of a possible nullable type. And any nullable types get converted into like a reflection union type when you have like null and the other type. Maybe this is a good test case to see if your code breaks.</p>
          </dd>
          <dt>Derick Rethans  10:50</dt>
          <dd>
            <p>I would probably call that a BC break though.</p>
          </dd>
          <dt>George Peter Banyard  10:53</dt>
          <dd>
            <p>This only happens if you do false union null. You can't use false currently on its own. And I think like, if you get false, as a named argument type, with like a question mark in front of it. Because it would be completely new, and you would never deal with it. It's like, well, this can also break because false can be in the Union type. If your library or the tool supports union types with the reflection thing, it will automatically know how to deal with false because it needs to know how to deal with it. And null. So that was kind of also the logic. It's like, well, okay, like if the tool supports that, which it needs to, then if you put this case into that bracket, it will work. It makes kind of the reflection code a bit more complicated at the moment. The whole fact that we need to juggle between like figuring out like, should we use the old like the backwards compatible thing reflection of like using a name type instead of the Union type, if there's a null and depending on the type, makes a reflection code unwindy and everything. And we have like a special function in C, which is basically just like, okay, which object do I need to create, depending on this type signature?</p>
          </dd>
          <dt>Derick Rethans  11:53</dt>
          <dd>
            <p>When do you think you'll be putting this up for a vote?</p>
          </dd>
          <dt>George Peter Banyard  11:56</dt>
          <dd>
            <p>I suppose I could put it up for vote immediately now. I am planning on maybe putting this on to vote at the end of the week or something like that.</p>
          </dd>
          <dt>Derick Rethans  12:04</dt>
          <dd>
            <p>Well, thank you for taking the time today to talk about this RFC.</p>
          </dd>
          <dt>George Peter Banyard  12:09</dt>
          <dd>
            <p>Thank you for having me on the podcast.</p>
          </dd>
          <dt>Derick Rethans  12:13</dt>
          <dd>
            <p>Thank you for listening to this installment of PHP internals news, a podcast dedicated to demystifying development of the PHP language. I maintain a Patreon account for supporters of this podcast, as well as the Xdebug debugging tool. You can sign up for Patreon at <a href="https://drck.me/patreon">https://drck.me/patreon</a>. If you have comments or suggestions, feel free to email them to <a href="mailto:derick@phpinternals.news">derick@phpinternals.news</a>. Thank you for listening, and I'll see you next time.</p>
          </dd>
        </dl>
      </div>
      <div class="articleSubSection">
        <h2><a name="show_notes"/>Show Notes</h2>
        <ul>
          <li>
            <p>RFC: <a href="https://wiki.php.net/rfc/null-false-standalone-types">Allow Null and False as Standalone Types</a></p>
          </li>
        </ul>
      </div>
      <div class="articleSubSection">
        <h2><a name="credits"/>Credits</h2>
        <div class="credits">
          <a href="https://incompetech.com/music/royalty-free/music.html">
            <p> Music: Chipper Doodle v2 — Kevin MacLeod (incompetech.com) — Creative Commons: By Attribution 3.0</p>
          </a>
        </div>
        <div class="patreon">
          <a href="https://www.patreon.com/bePatron?u=7864328">
            <img src="https://derickrethans.nl/images/become_a_patron_button.png" alt="Become a Patron!"/>
          </a>
        </div>
      </div>
      
    </div>
  </div>
</div>

Podurama

Home

Trending

Personal

Your Podcasts

New Episodes

My Files

Favourite Episodes

Tags (Folders)

Recently Played

Bookmarks

Followed Playlists

PHP Internals News: Episode 99: Allow Null and False as Standalone Types

PHP Internals News

AI Chapters

AI Insights

Reviews