This is an old revision of the document!

P++ idea: FAQ

  • Date: 2019-08-09
  • Author: Zeev Suraski, zeev@php.net

This is a clarifying FAQ for the idea presented on internals@. It attempts to address many points that were raised repeatedly in the discussion that ensued.

Note: P++ is a temporary code name and is subject to change.

What is this all about?

Trying to shorten the lengthy email into a couple of points:

  • There are two big, substantial schools of thought in the PHP world. The first likes PHP roughly the way it is - dynamic, with strong BC bias and emphasis on simplicity; The other, prefers a stricter language, with reduced baggage and more advanced/complex features.
  • There's no 'right' or 'wrong' here. Both schools of thought are valid, and have a very substantial following. However, it's challenging to create a language that caters to both of these crowds at the same time - which is a constant source of contention on internals@.
  • The proposal is to create a new dialect of PHP (code named P++) that will live alongside PHP, but won't be bound by the historical philosophy behind the language. In other words, this new dialect could be inherently more strict, it could be more daring with BC and remove elements that are considered 'baggage' (such as short tags), and adding more complex features - especially ones that are a good fit for strictly typed languages - without having to introduce the same complexity to the PHP dialect.
  • This is not a fork. The code base will be identical, the developers working on that codebase will be the same. The vast majority of the code would be identical. Only the specific points of difference between the two dialects will have different implementations. It is somewhat similar to what was done with strict_types in PHP 7 - only on a larger scale.

Do we really need to do all that just because some folks can't give up on short tags?

This is not related to short tags, and the short tags deprecation RFC was not the main motivator for this idea. The goal of this proposal is a lot more ambitious - it's to provide a clear vision for PHP - and to hopefully finally put to rest the tension between the two schools of thought on internals@ - by providing both of them with what they want.

Why fork PHP?

This is not a fork. The codebase will be identical, it would be versioned together and developed by the same people. The binaries will be identical - if you'd install PHP, you'd be installing P++ and vice versa. The same binary will be running your PHP, P++ or combined PHP/P++ apps.

While it's not yet clear how one would 'mark' a file as a P++ file, it would probably be some sort of a special header at the top of the file, such as:

<?php 'Hello, world!'; ?>

In addition, we may find ways to mark entire namespaces as P++, so that frameworks don't have to explicitly mark every individual file as P++.

This means doubling our dev efforts, while internals@ is already low on contributors. How will we deal with that?

Thankfully, it doesn't mean that at all. The vast majority of code will be shared between the PHP mode and the P++ mode - both in source and at runtime.

Data structures, key subsystems, extensions, web server interfaces, OPcache - and mostly everything else - will be be the exact same code running regardless of whether the file being executed is a PHP one or a P++ one. The only additional development overhead will be the specific areas of difference between PHP and P++.

It's true that it means we'd have to maintain two versions of certain pieces of code, and that we'll have some if() statements in various places - as P++ is likely to have additional checks compared to PHP. However, these are elements that would have to be introduced anyway if we're ever to move towards a stricter version of PHP. Moreover, since even folks in the strict crowd don't suggest that we move towards a stricter future without providing a migration path - effectively, the efforts involved with this approach and virtually any other approach are similar.

Why not just make a perpetual PHP 7.4 LTS and be done with it, as we move to a stricter PHP 8/9?

There are many issues with this approach. Even if we disregard the fact that this leaves the huge dynamic-preferring crowd hanging with no feature or performance updates - it's impractical from a development effort point of view. Unlike this proposal - this does, in fact, mean a de-facto fork.

Will I need to choose between PHP and P++?

Yes and no. As mentioned above, when you install one - you'd have the other - so as far as apps go - you'd be able to run both dialects on a single server. However, practically speaking, projects and individuals are likely to typically pick and standardize on one or the other - similarly to how things went down with strict_types.

Will I be able to mix and match PHP and P++ in the same app?

Yes. While we need to work out the exact mechanics, the designation of whether code is PHP or P++ will be at the file level - not at the request level. A single execution (request) may load many different files, and these files could be from both dialects. Code from PHP files will behave with the PHP semantics - while code from P++ files will behave with P++ semantics. Here too - this would be similar to strict_types.

While this may sound awkward at first - there could be very practical use cases for this. For instance - a P++ only framework that is being used by a PHP application - or vice versa. For those of you familiar with C and C++ - this is somewhat similar.

Does it mean PHP will no longer evolve? Will all new features go into P++?

No, it just means it'll evolve differently. Strictness and type related features are likely to go just to P++, and only be available in P++ files. Bias for BC will remain in PHP (which won't mean it would never be broken - just that there'd have to be good return-on-investment cases for each such case).

However - unrelated features - such as performance improvements in the engine (e.g. JIT), developments in extensions, or new async-related features - will be available for both PHP and P++.

What are the benefits of this approach?

There are numerous benefits to this approach. First, it gives both camps on internals@ - and beyond - a good solution to their aspirations. Those who prefer the dynamic nature of PHP get to keep it, while those who prefer a more strictly typed language - get to obtain it without being bound by any limitations of PHP. The alternative to that is a zero sum game - where the win of one group is the loss of the other, and vice versa.

Beyond being a good technological solution - that enables us to support our entire audience in the least amount of effort - this could also bring an end to key source of contention on internals@ in recent years.

Finally - although most of the readers of this document are likely to be technology people - it should be noted that launching P++ that would start with a clean slate - could have substantial positioning/branding advantages. Companies, development managers and individual developers who have ruled out PHP - are more likely to take note of a P++ launch, than of a launch of PHP 8.0 or PHP 9.0.

Aren't we risking fragmenting the userbase?

To a degree, we are. But this isn't a flaw of this idea - but a representation of reality as it already exists on the ground.

As mentioned above, there's a huge crowd out there that likes the dynamic nature of PHP, and looks warily at the attempts to make it more and more type-oriented.

At the same time - there's another huge crowd out there that looks at PHP and thinks to themselves “why is it evolving so slowly towards finally getting rid of this dynamic nonsense?”

There's no right or wrong here. Both points of view are valid. When we look at potential solutions to bridge between these two contradictory points of views, there aren't too many of them available:

  1. Stick with loose (aka weak) dynamic PHP. This will not be accepted by the proponents of a stricter language.
  2. Evolve towards strict (aka strong) dynamic PHP. This will not be accepted by the proponents of a loosely typed language.
  3. Fork the codebase. This is a net loss option for everyone involved, regardless of how it's done. There's no technological advantage to doing that, and we don't have enough contributors to do that even if we wanted to (which we don't).
  4. Come up with some creative solution to cater to both audiences. This is what this proposal attempts to do. It does that while keeping the project itself unified, and while ensuring perpetual interoperability between the two dialects - so that while there'll be some level of fragmentation, it will be the minimal one possible that still addresses everyone's primary needs.

How does this differ from Nikita's Editions idea?

There are many similarities between these two ideas, but also a couple of substantial differences. Note that this is based on a limited understanding of the Editions approach, so parts may be lacking, inaccurate or incorrect.

  1. In this proposal - there is a stated goal to keep the current, dynamically typed PHP - as a long term, fully supported, equal-among-equals dialect. The Editions approach views the current behaviors as 'legacy'. That means it may be discouraged, and then, at some point, deprecated and removed.
  2. The rollout strategy is quite different. The P++ proposal aims to first focus on the compatibility-breaking elements - things like strict ops, changes to type conversion logic, array index handling, requiring variable declarations, etc. - and aim to deliver them at the first installment of P++. That's with the goal of allowing new projects/frameworks to start fresh, without knowing that they'd likely have to undergo a major rewrite a year or two down the line when more compatibility-breaking changes are introduced. The Editions proposal appears to have no such goal - but instead, aims to gradually add/change elements in PHP.
  3. Related to rollout - the Editions approach doesn't allow for just two dialects - but any number of dialects. We could have a PHP2020 dialect, along with a PHP2022 dialect and a PHP2027 dialect. If we keep them all - this may actually increase our maintenance complexity.
  4. This proposal also mentions different BC-break strategies for PHP vs P++ (conservative vs. aggressive), while Editions will likely not touch that topic at all.
  5. The Editions proposal does not have quite the same positioning/marketing aspect that this proposal does.

It's important to note that the two ideas aren't necessarily mutually exclusive. We could introduce P++ and evolve it with editions, especially if it proves too difficult to get all the compat-breaking changes into the first installment of P++.

What are the challenges?

There's no shortage of challenges before we can run our first P++ app.

  1. We need to get buy-in. That means that folks from both schools of thought need to give up on a dream of having PHP be entirely dynamic or entirely statically typed while disregarding those who think differently from them. This appears to be a very substantial challenge.
  2. In order to be successful, the first version of P++ should deal with all, or at least most of compatibility-breaking changes from PHP - so that developers who make the (probably fairly painful) switch won't have to reaudit/radically refactor their code once more in the future. Some have voiced concern that they may be too optimistic to do in one installment with the limited developer-power we have. We'd have to evaluate that once we have a better idea of what that list is. Note that it does not mean we need to implement any and all ideas we may have for P++ at this first version - just that we should prioritize elements that would trigger substantial end-user code rewrites - and try to handle them before our first release.
  3. Of course, the most challenging of all - we need to find a reasonable name for this new dialect.

What are the general concerns?

The dialect won't be limited to loose vs strict

Progression of PHP may halt as any substantial changes are be opted to be done in P++ only. With the strict_types directive, it's clear that it's limited to loose vs strict types. The difference between PHP and P++ could be very broad and unintuitive.

Semantics should not be changed based on a flag

In the discussion of the strict operators RFC, serious concerns were raised for changing the semantics of an operation based on a directive (or any kind of flag).

Indeed. The directive may make operators more strict in what they accept, but it should avoid changing the semantics. Concretely, we must have either:

"120" > "99.9"; // true


"120" > "99.9"; // TypeError

Anything else will bring confusion.


Converting PHP code to P++ code is not trivial

For applications that do not rely on implicit typecasting, but use explicit casting or functions like those from the filter extension instead, not code needs to change to switch to strict type checking using strict_types.

The concern is that the syntax of PHP and P++ will grow apart to such an extent, that converting a PHP application to P++ would not be possible without a partial or complete rewrite.

PHP tooling will not support P++

There are a lot of tools available for PHP developers, like IDEs, testing frameworks, etc. Supporting both PHP and P++ requires effort from maintainers of those tools. Those maintainers might choose not to invest the time for support until P++ has a substantial user base. On the other hand, devs might choose not to P++ until it has proper tooling support.

It's not possible to do a cleanup without breaking PHP compatibility

So many times I have thought “is it time to just take an axe and simplify it and do a cleanup?”. I actually don’t think we lack many features but rather lots of stuff I would dump like references, array(), global namespace for functions(?), type juggling in areas where we should be stricter, etc...


Removing things like references, array() and the global namespace for functions would make it impossible to use PHP functions from P++.

Compatibility would only be one way

Introducing new data structures that only exist in P++, could make it impossible for PHP library to use P++ libraries.

P++ would have to do branding from scratch

What would be the plan to boost or change the reputation? How are you going to find P++ in Google? How are users searching for things with PHP and P++? What's the documentation going to look like for two languages that share so much? Specifically from a marketing POV splitting up the language into two makes no sense at all. Given PHP has no unified marketing message or a dedicated department it is much better to use the existing brand, with all its positive and negative perception and just keep rolling with it.

A strategy to change the security or any other perception of PHP is solely a marketing, teaching and persistence issue. As you say the language is already the fastest dynamic language with the best runtime. But “starting over” with 0 brand name and perception is much harder problem than changing the existing brand, and its not at all technical challenge.


The popularity of Python doesn't have to do with typing

In the case of Python, it seems to be the numerical, scientific and linear algebra libraries that's driving its popularity.


The popularity of Python is rapidly increasing at the cost of the popularity of PHP. Python is praised with simplicity. However, is uncertain to what extent the popularity is related to simplicity, and specifically typing, and to which is this related to better libraries (both core libs and user libs).

Is a new dialect really necessary?

I feel like both hardcore camps Zeev is describing are too way off base and want basically impossible. The BC crowd is just being unreasonable and only the tech that evolves realistically survives. You cannot have the BC cake and eat it, at some point you have to upgrade and update your application code.

The “upgrade everything, BC be dammed” crowd also needs to chill. If you are so impatient - there is Go, NodeJS with it's JavaScript/TypeScript, etc. Right now PHP does has somewhat of a plan and direction it is going, it is going at a decent pace - not too slow, not too fast.

Arvīds Godjuks

As an alternative, we could extend the effect of strict_types to throw a TypeError to most places where implicit type casting is done based on the context of the statement. This would make PHP a weak dynamically typed language without strict_types and a strong dynamically typed language with strict_types.

New and more strict data structures could be introduced. Attempts for this have been made through the SPL] and [[http://php.net/ds|Data Structures extension. However, support for this in both core libraries, extensions, and user libraries has been limited. New native types could prove to be more successful.

Functionality that's being deprecated and removed or unbundled is rarely used. The removal of php.ini settings makes PHP more uniform. The effort of switching from PHP 7 to 8 shouldn't be much more than the effort needed to switch from PHP 5 to 8.

I don't see these (or Generics which you also mentioned) as being inherently incompatible between more/less strict codebases.


New feature and new core functions (like a new string library) would not break backward compatibility.

pplusplus/faq.1565610842.txt.gz · Last modified: 2019/08/12 11:54 by jasny