Skip to content

Breaking changes in Haxe 3.3.0

Simon Krajewski edited this page Jun 3, 2016 · 11 revisions

Pattern matching

  • "Constant expression expected": The compiler no longer allows matching on non-inline fields unless they are read-only ((default, never)).
  • Pattern resolution order is now consistent with resolution order for normal typing. This might resolve an unqualified identifier pattern differently. Refer to http://haxe.org/manual/type-system-resolution-order.html for more information on how resolution order works.

Macros

  • @:enum abstract types are now transformed after their build macro has run. Build macros should no longer manually add @:impl and make the field static/inline.
  • It is no longer possible to use multiple type parameters named Const. Consider using the new @:const T feature instead.

Typing

  • Dynamic is now checked for when overriding or implementing fields in order to avoid variance violations.
  • typedef types are no longer checked eagerly. This might delay execution of some @:build or @:genericBuild macros. Note that type building order is undefined anyway.

Miscellaneous

  • Modifying a Map while iterating is no longer specified.

JavaScript standard compilance

Haxe now generates JavaScript code for ECMAScript 5 (ES5) compliant runtimes by default (this was enabled with -D js-es5 before).

This means that it can break for some browser that doesn't support ES5, such as Internet Explorer 8 and earlier. To keep ES3 compatibility, use the new define -D js-es=3.

If not set manually, js_es value will be set to 5 by default. In future, this define will be used for generating JS code for more modern standard versions.

When writing JS specific code, you can use conditional compilation expressions like #if (js_es >= 5) to have different implementations for different ES versions. The old js_es5 define is kept for backward-compatibility when js_es is equal or greater than 5, however it's advised to use the new js_es define instead.

Sys.command() and sys.io.Process

Haxe now specified how the input commands(cmd : String) and arguments(?args : Array<String>) are processed. As described in the API documentation:

Command arguments can be passed in two ways: 1. using args, 2. appending to cmd and leaving args as null.

  1. When using args to pass command arguments, each argument will be automatically quoted, and shell meta-characters will be escaped if needed. cmd should be an executable name that can be located in the PATH environment variable, or a path to an executable.
  2. When args is not given or is null, command arguments can be appended to cmd. No automatic quoting/escaping will be performed. cmd should be formatted exactly as it would be when typed at the command line. It can run executables, as well as shell commands that are not executables (e.g. on Windows: dir, cd, echo etc).

In previous versions of Haxe, cmd and args may not be properly handled. Particularly, handling of spaces and shell meta-characters (\, ', " etc) are not reliable. You may have employed manual workarounds like quoting cmd as follows:

Sys.command('"' + exe + '"', []);

In Haxe 3.3+ you should remove the workaround as follows:

// When using the `args` argument, remove the custom quoting around `cmd`
Sys.command(exe, rawArguments);

// Or, use custom quoting and do not use `args` (leave blank or pass `null`)
Sys.command('"' + exe + '" ' + escapedArguments);