Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[php7] null coalescing operator not supported #4166

Closed
fredemmott opened this issue Nov 7, 2014 · 15 comments
Closed

[php7] null coalescing operator not supported #4166

fredemmott opened this issue Nov 7, 2014 · 15 comments

Comments

@fredemmott
Copy link
Contributor

http://3v4l.org/qLYI8

<?php

var_dump(1 ?? 2 ?? 3);
var_dump(1 ?: 2 ?: 3);
@reeze
Copy link
Contributor

reeze commented Nov 9, 2014

Which version of HHVM should have this feature? HHVM3.6? or HHVM3.9? I am interested in implement it but will it get merged if the current master version is not aimed to be compatible with PHP7?

@SiebelsTim
Copy link
Contributor

This doesn't break any previous versions, does it? Also we have some PHP7 features already in master.

@Majkl578
Copy link
Contributor

Majkl578 commented Nov 9, 2014

Master should be bumped to PHP_VERSION_ID=59999 or something to indicate support for PHP >5.6.

@paulbiss
Copy link
Contributor

paulbiss commented Nov 9, 2014

I haven't done a feature audit, but we definitely don't have full parity with all PHP 5 versions. That being said we have been adding PHP 7 features along the way. @reeze if you'd like to take a crack at it by all means send us a PR, @andrewparoski would be the best person to talk to about it.

@reeze
Copy link
Contributor

reeze commented Nov 10, 2014

Alright, I will go head and try to implement it.

@FightingMan
Copy link

@reeze thumb up

@ptarjan
Copy link
Contributor

ptarjan commented Nov 10, 2014

@Majkl578 that's a good point. Since we are matching PHP5 (and PHP7) as much as possible on new features we should probably match the constant they are using in their development branch. Although it will be a difficult moving target since we'll say we have PHP7 support in some version (say 3.4), but it won't be complete support since they will surely add more features before their next release that won't be in 3.4. Then if people do feature gating on PHP7 when running HHVM 3.4 it won't work.

What would be best for users?

@staabm
Copy link
Contributor

staabm commented Nov 10, 2014

@ptarjan maybe it would be better to promote feature-testing for hhvm/php compat instead of checking for version numbers

@reeze
Copy link
Contributor

reeze commented Nov 13, 2014

@staabm hmmm but syntax feature is not easy to test.

@Jo-Con-El
Copy link
Contributor

I think it would make more sense to decide whether we want e.g. 80% compatibility and then we flip the switch (i.e. assume that we are able to run it). Or maybe we are not able to say which percentage of compatibility we keep right now. @ptarjan?

@fredemmott
Copy link
Contributor Author

A concrete percentage doesn't really fit. We've tended to do it when we've implemented all the major new language features and aren't aware of any real-world blockers.

@Jo-Con-El
Copy link
Contributor

Then maybe a blog post or a comparison table? :-)

@fredemmott
Copy link
Contributor Author

For now, we want compatibility with PHP5. We are generally adding PHP7 features that don't break backwards compatibility. Given PHP7 is nowhere near final, and we're not actively targeting compatibility with it yet, the doesn't seem much value - the comparison would likely be useless by the time there's a stable release of PHP7. If you'd like to continue this discussion, it'd be better on https://www.facebook.com/groups/hhvm.dev/ or as a documentation issue. It's really orthogonal to this issue.

@SiebelsTim
Copy link
Contributor

duplicate #5500

@JoelMarcey
Copy link
Contributor

closing in favor of #5500

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants