http://hhvm.com/blog/2021/04/22/removing-implicit-coercions.html

普通更新

tl/dr: we’re doubling down on removing surprising implicit (and some explicit) coercions from the language. So far we very close to having object → num conversion trigger exceptions
have pieces in flight for the removal of coercions due to string interpolation/concatenation, mathematical operations (including bitwise), and pre/post increment/decrement
have concrete plans for comparison operators, the (in)equality operators, and switch statements.ContextImplicit coercions can be unintuitive in edge cases, and these edge cases can be surprisingly common - making them the second most confusing language feature, behind arrays. Even those working on the language often make mistakes, and they are frequently a source of subtle bugs.For those who don’t know, an implicit coercion is when a value of type A gets converted to type B as part of computing the result of an operation. Probably the most common example is how 0 == false results in true courtesy of 0 being converted to false prior to the comparison, but things go straight downhill from there (hint: try comparing '0' with false and then '0' with null). We’ve determined that the time has finally come to tackle this once and for all.So what are we going to do about it?Well, we’ve actually already started doing something about it! Very shortly, attempting to convert an object into a number will universally throw an exception. On top of this almost finished step, we have a few portions in flight, as well as a few more not started but still very much planned.For the following, the possible stages are No Progress - Allowed by both the Type Checker and runtime. Lints may exist.
Enforced By Type Checker - the Type checker will report errors
Soft Runtime Enforcement - Violations may trigger logs via the runtime, configurable via flag.
Hard Runtime Enforcement - Violations will produce a runtime exception
New Behaviour - Following stage 4, we may decide to re-allow the operation but with a different result.These stages are ordered such that by a certain stage, all previous stages are implied.String Concatenation (. , .=) interpolationCurrent Behaviour:
int, null, bool, float, and resource will implicitly coerce to string1
'' . true; // '1'Future Behaviour:
only int will implicitly coerce. The rest will trigger exceptions
Example:1
2
'' . true; // `InvalidOperationException`
'one: ' . 1; // 'one: 1'Status of rollout:
Soft Runtime EnforcementBitwise operations (&, |, ^, ~, ) and assignment equivalentsCurrent Behaviour:&, |, ^: null, bool, float, vec, dict, keyset, and resource will implicitly coerce to int. strings will implicitly coerce as well unless both operands are strings.1
2
3
null & vec[]; // 0
keyset[1] & true; // 1
'abcd' & 'efgh'; // 'abc`'~: floats will implicitly coerce to int1
~1.2; // -2: null, bool, float, string, vec, dict, keyset, and resource will implicitly coerce to int1
keyset[1] = false; // true
false < new Foo(); // true
false < Foo::class; // true
true < Foo::class; // false
true > Foo::class; // falseFuture Behaviour:
Comparing values of two different types will throw an exception. A notable exception to this will be comparing ints and floats. In that case, comparison works as you’d expect, with the usual caveats about comparisons involving two approximately equal floats (including an approximately equal int and float).1
2
3
4
5
null >= false; // InvalidOperationException
false < new Foo(); // InvalidOperationException
false < Foo::class; // InvalidOperationException
true < Foo::class; // InvalidOperationException
true > Foo::class; // InvalidOperationExceptionStatus of rollout:
Enforced By Type CheckerEquality operations (==, !=)Current Behaviour:
All the same combinations of types trigger coercions as with the comparison operators, but with even more situations resulting in coercions.1
2
3
4
null == false; // true
false == new Foo(); // false
false == Foo::class; // false
true == Foo::class; // trueFuture Behaviour:
There will be two steps to this, going through both Hard Runtime Enforcement and then New Behaviour. First, comparing values of two different types will throw an exception. Then, comparing values of two different types will simply be false.1
2
3
4
null == false; // InvalidOperationException then false
false == new Foo(); // InvalidOperationException then false
false == Foo::class; // InvalidOperationException then false
true == Foo::class; // InvalidOperationException then falseStatus of rollout:
No ProgressSwitch statementsThis is may be a surprise to you, but switch statements utilize == under the hood and so result in all the same coercions. As such, refer to that section for current and future behaviour.Long TailIn addition to the above major operational line items, we continue to discover a long tail of more minor coercions that will necessarily be tackled by this work, including things such as indexing into strings with other strings.Next StepsAfter this change, == and === will be very similar semantically, with the only major remaining differences appearing when operating on arrays and objects. This could make it confusing which one should be used. As a follow up, we will evaluate potentially removing one of the operators.Additionally, there are a handful of above operations that don’t trigger coercions but we consider dubious nonetheless. Examples of this include bitwise operations and inc/dec on strings. As a followup, we will consider what to do about these operations.

HHVM (HipHop Virtual Machine)会将PHP代码转换成高级别的字节码（通常称为中间语言）。然后在运行时通过即时（JIT）编译器将这些字节码转换为x64的机器码

暂无

暂无