Default values not always correct

[Aidan63]

Several places in the coroutine branch use Texpr.Builder.default_value to get a default value for a type, the problem with this function is that it often gives default values which aren't correct. There are two main things it gets wrong.

• Many targets have core type abstracts which represent properly sized integer types, default_value returns null for these which is not correct.
• haxe.Int64 gets a default value of null, which is fine for some targets, but not targets which use a native 64 bit int.

The easiest solution would be to add a bunch of cases for all these known target specific types so they get reasonable default values, as well as pulling in some sort of context so we can check the target and return a appropriate Int64 default value.

Maybe a better solution to prevent an ever growing list of types would be some sort of defaultValue metadata, e.g. @:defaultValue(Int64.ofInt(0))? That would require default_value to do typing though.

Alternatively do nothing and have the coroutine branch attempt to deal with it.

[Simn]

How about adding a_default : texpr_expr which is lazily initialized from the metadata when loading an abstract? Then the implementation of default_value can use mk a.a_default t p after matching TAbstract(a, _).

[Aidan63]

Yeah, that does sounds like it would work. I'll have to have a play around.

[0b1kn00b]

This is why I'm banging on about constructors elsewhere, there's things that absolutely don't have a default value, but equally quite a lot of things can be bootstrapped. I think it requires that object fields are ordered everywhere so that shortlex comparisons work.
(edit) here's a canonical dependency injector from the inimitable @nadako here
It's quite straight forward.