The PHP 7 Revolution: Return Types and Removed Artifacts

With the planned date for PHP 7’s release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I’d like to focus on three that grabbed my attention.

PHP 5.7 vs PHP 7

As I mentioned in the last newsletter, 5.7 has been downvoted in favor of moving directly to PHP 7. This means there will be no new version between 5.6 and 7 – even if the new version was only to serve as a warning light to those still stuck on outdated code. Originally, 5.7 was not supposed to have new features, but was supposed to throw out notices and warnings of deprecation about code that’s about to change in v7.

It would also warn about some keywords that are to be reserved in PHP 7, so that people can bring their code up to speed with a sort of “automatic” compatibility checker in the form of an entire PHP version. The thing is, however, as I argue in the newsletter, that most people technologically competent enough to follow PHP in its upgrade path by keeping up with the most recent version aren’t generally the type of people to actually be using code that might break in PHP 7.

Note that while the voting is over, that doesn’t prevent it from being resurrected at a later point in time. The “nay” voters in the first round seem to have argued against 5.7 due to the lack of significant changes, but with recent changes and new votes on other RFCs, that may well be reconsidered. Let’s see what happens.

Return Types

With a vast majority voting “yes”, PHP is finally getting return types. The results of the vote are still fresh, but definite. Starting with PHP 7, we’ll finally be able to indicate proper return types on functions in the form of:

function foo(): array {
    return [];

An improvement? Definitely! But perfect? Unfortunately, no:

  • the return types can only be what we have for types right now, meaning no scalar values, no return types like string, int, bool, etc. This means that your methods and functions that return such values will still be unsigned. You can remedy this by returning instances of wrappers for such values, but that’s overkill in the vast majority of cases.
  • no multiple return types. If your function returns either an array, or an Iterator object, there’s no way to indicate that via, for example, array|Iterator as we do in docblocks.

Some people also complained about the type declaration being after the closing parenthesis of the argument list, rather than before the function name, but to me, this is nitpicking. Popular languages such as modern C++ use the “after” syntax, and like the RFC states, this preserves the possibility of searching for “function foo” without any necessary regex modifications. What’s more, this is in line with what HHVM uses, so it’s an added unintended compatibility bonus.

Others complained about the “strictification” of PHP, but as one commenter states, you really find the value of this when you start coding against interfaces or inheriting other people’s code. Besides, as long as it’s optional and its existence does not in any way affect PHP’s general performance or stability, there’s no harm in it. Complaining about it is, to me, akin to complaining about OOP being added to PHP when procedural spaghetti worked so well for most cases back then. Languages evolve, and this is a step in the right direction.

What do you think?

Removing Artifacts

The upcoming version proposes to remove PHP4 style constructors (yet to be voted on). You can read what this means in the RFC, it’s simple and would be futile to repeat it here – but what’s actually very interesting is the mental anguish such a move seems to be causing some people. For example, this. “Please do not break our language”, pleads Tony, who seems intent on using its broken features.

The post is well written despite the obvious anger, but it makes me wonder – if you’ve kept such a codebase alive for so long, is there really a need to upgrade to PHP 7? And if there is a need to upgrade to PHP 7, is it not easier to simply hunt down the offending classes and fix their constructors? Surely this is something you can delegate to juniors, given enough unit tests in your code base to make sure it all goes well? And if you don’t have unit tests, if your app is a mess, do you really hope to benefit in any way from moving to PHP 7? Wouldn’t you be better off Modernizing your Application first?

The sentence “This means that code which I wrote 10 years ago should still run today, and should still run 10 years from now.” is, to me, madness – you definitely and absolutely should not expect this of ANY language across major versions. To draw a parallel from the real world, you shouldn’t expect to be allowed to own slaves today just because a law from long ago said you could. Yes, the BC break came after a bloody revolution, but when most slaveowners repented or died, there was peace.

Granted, Tony is right in that it would take effort to remove the feature, while it would take none to leave it in. But in the long run, it will take more collective effort to fix the problems these constructors sometimes cause, than to remove it right now.

Understandably, BC breaks always upset some people, even if major versions are perfectly okay having BC breaks for the purpose of progress. But imagine the fervor when such people find out about this. Heck, imagine what would have happened if WordPress hadn’t stepped into 2001 last year and updated to mysqli instead of mysql – either no WP installation would work on PHP 7, or PHP 7 would keep an unsafe and long deprecated feature for the sole reason of keeping WP users happy.

My advice to those fearing PHP 7 is – stop. If you don’t want to upgrade, don’t. If you could be on 5.3 or 5.2 for so long (looking at you, CodeIgniter), you can be on 5.6 for another decade – but let us have modern PHP. Leave progress up to those who are willing to accept it.

What say you? Is this removal of artifacts nonsense or needed?

Aside: Extension API Changes

As an interesting sidenote, there are some changes in PHP 7 that might actually cause a bit of a delay with extension porting to version 7. The API for building PHP extensions is still under a revamping (read: cleaning) process and all is subject to change – nonetheless, this provocative tweet from Sara Golemon gathered quite a bit of attention.

She basically says the changes in extension development from 5.6 to 7 will be so great, you might as well learn how to make HHVM extensions. She then proceeded to craft a lengthy series on that exact topic, explaining in depth and on examples how to create an HHVM extension.

Do you develop extensions? Did you study the changes, or do you feel like it’s still too early to tell if they’ll have an effect?

Edit: It has been brought to my attention that Sara has later started documenting a new extension API compatible with both HHVM and PHP 7. We could – it seems – have extensions compatible with both runtimes!


As usual, there’s no shortage of drama in PHP land. Like all major revolutions throughout history, the PHP 7 revolution will also be spilling some blood before producing something awesome. PHP 7 is still a long way off, so even if you’re caught in the crossfire of musket shots, there’s ample time to get to cover. Unless you’ve been sleeping under tank tracks, then there’s little either side can do to help you.

What do you think of these RFCs? How do you feel about PHP 7 in general? Is it heading in the direction you’d like it to head in? Let us know – we want to hear your thoughts!


  1. swader says:

    Thank you for the response, I’m glad to have you chiming in here!

    The problems have been named in the internals list, and have been, in part, mentioned in your article. Some breakage here and there and unexpected behavior. Nothing critical from my point of view, but it happens nonetheless.

    I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?

    And what is the status of these languages today? How used are they? How many courses do you see on them? How many newbie developers ask “Should COBOL be my first language?” rather than inquiring about PHP?

    On a final note - I’d like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort? Surely if you search for all instances of such behavior and have a sufficient amount of unit tests in place you could fix all of it in a day or two? I really am curious as to the nature of your application that is so brittle such a change would destroy it, and yet still incompatible with minor code alterations as to avoid this disaster.

  2. While I personally do not have the same view on the changes that is happening in PHP 7.0, I completely agree on that any functionality that is removed should be deprecated first.

    At the same time, I do not believe this is what ruin the confidence in the language, what does that is the inter-tangled mess of internal function names, the order of parameters across the internal functions, poor support for multibyte charsets (not all of the internal functions support it) and missing vital data types like Decimal.

    We are working with Enterprise solutions as well, and we cannot wait until the new version is released due to massive improvements to the internals, both for the speed increases and making it easier to make extensions. This alone should be enough for anyone to update their code base if they are using any of the functionality that is removed.

  3. If a business needs to run a piece of code, to me this also implies actively maintaining it. TonyM subscribes to the write and forget view which may also be the view of many others, including corporates, but I think that dev paradigm is very risky and short sighted.

    Important code, whether it is mission critical or not, should always be in active maintenance. Code which is no longer needed, can be junked, but if any code is still used, even if just once per year, it should be in the active maintenance pool and assigned to one or more coders to keep up to date.

    I have my own projects and I actively maintain everything which my business depends on. I also engage in code reviews every 3 months and refactor code if needed.

    I do not subscribe to the “if it ain’t broke, don’t fix it” paradigm. I believe that all code is inherently broken (has bugs) and constant code reviews, refactors, rewrites, are there to eradicate bugs and improve my code.

    If the language changes, code must also change. That is the only dev paradigm that makes sense, because progress is a good thing and we should not hinder it.

  4. Yup, SQL injection vulnerabilities. Mail header injection vulnerabilities. Global variables up the wazoo. Control logic mixed with DB logic mixed with validation logic mixed with… pretty much every other kind of logic. And did anyone else notice he invented his own password encryption? He’s basically made every amateur mistake in the book. And, guys – I did this for your benefit. If he ardently defends this code as well structured, easy to read, and easy to maintain, then you’ve got to know you’re never going to get anywhere in this discussion. PHP will continue evolving despite Tony’s objections. Let’s be happy with that.

214 more replies