We have decided to skip this week’s regular release, HHVM 4.63.
There have been some bugs that prevented us from publishing the release earlier this week. Instead of shipping the release only a few days before the next one, we decided to skip it.
Support for HHVM 4.57 will be extended until the release of HHVM 4.64, scheduled for next week.
We expect next week’s HHVM 4.64 to contain some significant changes affecting legacy (PHP-style) arrays.
- We expect
array(...)literals to be completely removed in the next release. All code will need to be migrated to
darray[...], or preferably
dict[...](if it can be done safely).
- Automated migration is available in HHAST
v4.33.6 or newer:
- Automated migration is available in HHAST v4.33.6 or newer:
- The INI flag
hhvm.hack_arr_compat_specializationwill be removed and its behavior will be enabled by default. We highly recommend enabling this flag in your current HHVM release before upgrading to HHVM 4.64. This change disables the implicit inter-operability between
darraywill be treated as types in their own right. Specifically:
- Using a
darrayis expected (at parameter and return value typehints) will throw, and vice versa. The same goes for property typehints, if they are checked at runtime.
varrays will now maintain a “
vec-like” layout, with integer keys from 0 to (size - 1). Attempting to set a string key in a
varraywill throw, as will attempting to unset any element other than the last one.
- Tuples and shapes are internally represented as
darrays, respectively. As a result,
darray is tuple(...)will return
darray as tuple(...)will throw. The same goes for
varray is shape(...)and
varray as shape(...).
- Comparing a
===will always return
- Attempting to compare
darrays relationally with
>=will result in an exception.
- Using a