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.

Flash 9

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.

PHP

Php does not handle integer overflow situations like strongly typed languages. 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. This can cause unexpected behavior, especially when used with other Haxe code that relies on strict type adherence. 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. Currently, it is impossible to fix this problem while maintaining efficient math routine performance.

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.

CPP

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.

JS

Reflect

When using Reflect.setField(), any getters and setters for the field will be ignored, and the field will be set directly.

parseInt

Note: this quirk has been addressed on svn and is expected to be included in v 2.07. For a better understanding of the new behavior, see the relevant diff.
The original parseInt for js targets treats inputs that start with 0 as octal by default. Accordingly, Std.parseInt("09") will return 0 in many browsers. This is appropriate according to a given ecmascript specification, but is a common source of errors for numeric parsing. In order to prevent this behavior in standard javascript, it is necessary to specify a base as a second argument of the parseInt function (e.g. parseInt("09", 10)). However, the Haxe version of this function does not provide a second argument, so this solution isn't appropriate in Haxe code. All other Haxe targets use native parseInt implementations that parse "09" as 9.

Suggested workarounds include stripping leading zeroes from strings in javascript for conversions in order to provide a uniformly behaving method:

    public static function parseInt(str:String):Int{
        #if js
            str =    ~/^0+(\d)/.replace(str, '$1');
            untyped return __js__('parseInt')(str);
        #else
            return Std.parseInt(str);
        #end
    }

For an overview of the situation, see the parseInt documentation and this stackoverflow response