@fabpot when bumping the version to 4.0, you forgot to update all inter-component requirements to allow them to use the 4.0 version of other components in their own 4.0 versions

Looks like this requires us to drop HHVM, impossible to make it run on the CI. I'm fine with that personally.

Poll here:https://twitter.com/fabpot/status/865080534669635584

In addition to the poll,according to the latest global PHP stats, HHVM is used by 0.36% of PHP developers. The number is practically zero ... but maybe there are some high-profile clients there (Facebook is using it, Slack was thinking about using it, ...)

@javiereguiluz please don't forget that the stats are about number of composer installs.. That doesn't translate 1:1 to users, as some may do more installs than others. I think it's mostly interesting to see trends over time as exact point-in-time numbers can't be fully trusted.

@nicolas-grekas HHVM has 2 modes: PHP 5 mode and PHP 7 mode. IIRC, it runs in PHP 5 mode by default. We should addhhvm.php7.all = 1 in the HHVM INI file.

I just tried again this mode, same failure. We'd need a php7.1 mode. There is just no way currently to make hhvm run on a 7.1 code base. HHVM advertises itself as 70099 so even Composer cant.
Just dropping for now.

Have you tried using the latest HHVM rather than 3.18 ? they may have updated their PHP 7 mode to expose it as 7.1 later

Yep, 3.19 locally, same result

Thank you@fabpot.

;)

Is this just a version number issue? HHVM can change what version number it gives back. Are there some PHP7 features we haven't implemented yet that are making it burdensome for Symfony to support HHVM?

That's not the only issue because even with the branches that support php5.5 thus hhvm, once you enable the php7 mode the test suite fails to just run, with strange type issues being reported.
It's quite easy to reproduce: just try running the ./phpunit script in this mode on e.g. 3.2.

We have an suboption to PHP7 that can disable the strict type checks. The strict type checks are broken in some cases, and we have that on our radar. It happens to not be trivial to fix, and also currently not at the top of our priority list.
The option ishhvm.php7.scalar_types=0

Will Symfony 4 use scalar type hints and return types? This would be a break to the 3.x versions, but with a major release the best time to introduce them.

@SenseException we will use them in new APIs. But we won't add them in existing interfaces, as this would be a BC break without a progressive upgrade path, and so the drawbacks are much bigger than the benefits for the community.

Btw, the master branch already contains a scalar typehint in at least one place (the last argument in

@stof I'm aware that this would be a bold move, but your argument also fits to a future Symfony 5, 6, 7 and so on. Implementing an old Symfony 4 interface forces a user to omit type hints even when it is a new project that never was on version 3 before.

But it seems that a return type can be added to the class implementing an interface that misses that type:https://3v4l.org/BHlVW.

@SenseException yes you can add return types to implementations, even when the interface doesn't require them. But doing this would be something for Symfony 5 so developers can first upgrade to Symfony 4, add the return-types, and then when Symfony 5 is released they can safely upgrade.

So Symfony 5 is going to have the type hints and return types? I just want to read when Symfony and its components arr going to use modern (2017) PHP.

We'll use type hints and return types for the new code. It's not possible without a BC break for the old one (and it has very little interest because, as pointed out by other people, you can use type hints in your code and our code base is well tested).

@SenseException in addition to what Kévin told you, we can only use PHP 7 features for new code added to Symfony. For the existing code, we can't use PHP 7 until November 2021 (as explained in this comment:#22862 (comment))

@javiereguiluz Thank you for pointing me to the comment and the answer to my question.