Anon type(s)

[ousado]

Which kinds of anons do we want to support?
we need C-style structs for externs (we can't easily have a header for these)
we need something more strict than the wibbly wobbles that "normal" anons turned out to be. Can we somehow make an abstract for {a_status = Const}, so we have an actual type for them? Something like

var v = {a:1,b:1}.const();
$type(v); // ConstAnon<{a:Int,b:Int}> 
var v2:ConstAnon<{a:Int,b:Int}> = v;

var x:{a:Int} = v;   // extra field error
var x:{a:Int} = v2; // extra field error

That shouldn't be limited to genc, I think, haxe as a whole could profit from being able to distinguish these by type.

And then we have to decide on "normal" anons. How far do we want to go to make them fast?

Pro: Structural subtyping is certainly nice, that'd be a good reason to put some effort in. It looks as if complete knowledge which anons occur at all, and as a bonus where they occur, and more importantly where most of them do not occur, ordering fields, and checking against and preparing class structures for anon access, can go a long way towards at least the fastest future anon implementation.

Contra: There are also optional fields, which are a horrible already, and finally the non-existent frontier between anything type-ish and Dynamic<Dynamic> which can be so easily crossed by Reflect.setField.

As for optional fields, they could be supported much better if we had slightly different semantics:

typedef AOpt = { var a:Int; @:optional var b:String; };
var v:AOpt = { a:Int }; 
var v = ( { a : 1} : AOpt ); 

If these would create an object with both fields directly instead of physically adding them later, we could have something less problematic. I'm not sure about @:optional value types - can they ever be non-Null? Does {@:optional x:Int} make any sense (except, perhaps as a syntactical convenience that turns the type into {@:optional x:Null<Int>})?

[ousado]

On further thought, I'd prefer to tag normal anons as Wobble<{...}> (or whatever) so the convenient notation wouldn't need the syntactic overhead for the ConstAnon case. Since that's probably unfeasible it would be kind of nice to be able to mark classes as @:constanon, which would per default assume ConstAnon<T> and require to annotate wobbling anons as Wobble<T>.