HaXe provides a common language and API for a large number of targets, and in most cases a Haxe application behaves identically regardless of target.
However, certain target languages and runtimes still have fundamental differences for basic types and operations that should be considered when developing. Many of these differences are bugs that will be fixed in subsequent versions. However, in some cases fixing the bug leads to an unacceptable loss of performance, or some other problem. These bugs should be considered as `quirks' that are the responsibility of the programmer to accommodate in their code for a given target.
This page will list all of these platform or general behavior quirks as they are uncovered.
The Flash9 target does not automatically allow nullable values for Floats, Ints, or Bools. This is done primarily for speed reasons, since nullable types are not as fast for mathematical operations on these targets. If a nullable value type is absolutely required, it is recommended to use the Null<Float>, Null<Int>, or Null<Bool> parameterized type instead.
Integer overflow has "undefined" behavior in Haxe, but in php it behaves as follows:
When a numeric operation makes a variable larger than the maximum integer value (which in turn can differ between 32bit and 64bit versions), php will automatically convert the integer to a float. Developers should be wary of this behavior in php targets, and should consider using conditional compilation so that any modifications of integers always produce integers for php targets.
The EReg class' API specifies that when the "matched" method is called on a non-existent regular expression group, an exception is thrown. Due to an implementation detail in PHP's regular expressions, the behavior is different from the API's specification. Calling "matched" on a non-existent regular expression group will return null instead of throwing an exception.
The Null<Float> etc from flash also applies to the cpp target.
If you pass an array of a non-dynamic type to a function that takes an array of Dynamic, the array will be copied. This will be a performance hit, as well as preventing you from returning modifications to the array. One can set the function as inline to workaround this.
The order of evaluation of sub-expressions-with-side-effects within a given line is not well defined. Usually it is in fact the opposite of the "haxe" order - ie, right-to-left. eg:
callFunc( sub1(), sub2() );
will evaluate sub2 before sub1.
When using Reflect.setField(), any getters and setters for the field will be ignored, and the field will be set directly.