Future Language Features
Nothing here can be considered to be definitive until implemented in the compiler, you are then welcome to suggest improvements on the mailing list.
Local Functions
Allow "this" (and member variables/methods) to be referenced from within local functions declared into member methods (i.e automatic "var me = this" creation).
This should be nearly 100% backward compatible, apart from a few std methods injections (and iterators) which are using "this" as the current object.
Properties Reflection Support
The idea is to add proper API (and runtime support) in the Type class in order to be able to list the properties of a given class, with its getter/setter methods.
Multitypes
function foo( x : Int|String ) { switch(x) { case Int: // x is Int case String: // x is String } } class Foo<T: Int|String> { var data : T; }
A multitype is a new type that consists on several subtypes : these subtypes need to be runtime-checkable (no structures, no type-parameters, no Dynamic).
The semantics of switch is changed when used on a multitype. It requires a case for each subtype (or "default"). In each case expression, the variable is retyped accordingly to the matched subtype.
Optional Structure Fields
We propose to be able to annotate some structure fields as optional by using ? marker :
function foo( init : { ?x : Int, y : Int } ) { }
The x field type automatically become Null<Int>.
This enables one to call foo with a constant structure that does not declare the x field, such as :
foo({ y : 55 }); // ok, 'x' will be null
We can't call it with a not-constant structure due to structural subtyping :
var s : { y : Int } = { y : 55, x : "Hello" }; foo(s); // x will be typed as Int but would be a String
SWC Input
Then ability to link one of several SWCs. This will replace --gen-hx-headers and provide better interoperability with Flex and other AS3 libraries.
The main issues to solve are the ability to override protected AS3 methods as well as native getter/setters, and to properly link several SWCs together, while including only the classes that are used.
The following features are required to implement them :
- metadata support (to store protected, namespaces, etc)
- mutiple
--swf-lib
Literal Hashes
The ability to declare literal hash tables :
var x : Hash<String> = { hello => "World", "Welcome back" => "home" };
haXe XML Format
The ability to output an XML representation of a fully typed haXe program (after typing but before code generation), and the ability to also load such XML representation, in order to enable 3rd party tools to perform additional tasks before final compilation.
RTTI Changes
Currently only classes can implements haxe.rtti.Infos in order to get an extra static field __rtti which contains RTTI informations encoded as XML.
The idea is to enable any type to have rtti by using metadata syntax :
@rtti enum E { .... }
And to add a specific API to retrieve these RTTI informations :
var r = haxe.rtti.Infos.get(E);
It should also be possible to replace the current XML format by some native format by using directly haXe data structures to construct the RTTI informations.
One possible extension for this feature is the ability to represent, at runtime, some types that cannot be represented currently, and thus cannot be checked (such as structures types).
However runtime checking of parametrized types is still quite hard to obtain.
Also, the Anonymous fields are not proper fields (in particular they don't have get/set accesseses) so this needs to be fixed.
Removal of Temporary Stack Objects
Thanks to inline, some objects no longer have methods actually called. But they still need to be allocated in order to be used. The idea is to optimize the following program :
var p = new Point(5,10); return Math.sqrt(p.x * p.x + p.y * p.y); // inline version of ''p.length()''
into the following by moving Point member variables on the stack and inline the Point constructor code as well :
var p_x = 5, p_y = 10; return Math.sqrt(p_x * p_x + p_y * p_y);
Flash9 Binary Tags
Store the resources linked with -resource into a Flash9 native binary tag (they are currently serialized in base64 so might take a bit of time to decode).
Anonymous type parameters contraint
Allow the following :
typedef Foo = { function foo() : Void; } class A<T : Foo> { }
Constraints in method parameters
Be able to do the following :
function foo<T:Float>( x : T, y : T ) { return x + y; }
Abstract types
The ability to declare abstract types which are a good way to represent basic types which cannot really be considered classes or objects :
abstract Void; abstract Float; abstract Int > Float; abstract UInt > Int < Int; abstract Int32 < Int { public static function foo( v : Int32 ) { } } abstract Class<T> { .... move Type API here .... } abstract Enum<T>{ ..... move Type API here .... }
There is an automatic "using" done on abstract types in case they have some static methods.
Package Changes
The idea is to group some common classes which are currently shared by Neko/Php/C++ : they have been separated since theses targets have been added incrementaly, but maybe should be group into a single package for all "system" languages.
Either haxe.sys or a new sys toplevel package.
Concerned classes are :
neko.Sys, neko.FileSystem, neko.db.*, neko.io.*, neko.net.Host, neko.net.Socket*, neko.zip.*
I guess such change needs appropriate thinking about package organization in haXe, especially if we think about possible future mainstream targets such as Java and .NET
Macros
The ability to have some haXe code executed at compile-time instead of runtime, to perform complex code manipulations.
Example :
import haxe.syntax.Expr; class Check { @macro public static function encodeString( e : Expr ) : Expr { return switch( e.expr ) { case EConstString(s): EConstString(StringTools.urlEncode(s)); default: throw new haxe.syntax.Error("Should be a constant string",e.pos); } } } .... var x = Check.encodeString("i am str"); // will get compiled as "i%20am%20str" var y = Check.encodeString({ x = 3; foo(); }); // will throw an error "Should be a constant string"
When a macro function is called, all parameters are passed as Expressions before being typed. Then we evaluate the macro with some haXe interpreter in the compiler, which returns an Expression or throw an error. The expression is then typed in the context it is generated.
It might be necessary to pass an additional parameter to macro-functions containing various things such as current local variables, current class/method, etc.