dcodeIO

Reminds me that there is a related mechanism already doing something similar: ```ts @final @unmanaged class Stacky { @inline constructor(value: T) { return changetype(value); } get value(): T { return...

You know what, if you say this is good, let's just do it this way :)

One thing I am not sure of is that each `Date` instance has a new reference to `BaseCalendar`. Is this actually necessary? Looks like BaseCalendar could also be implemented in...

It's a shame that I haven't reviewed this more thoroughly. Looking at it again I think that this went stale in my head because it needs so many managed objects...

That would be fantastic, yeah. To elaborate a bit on the C-likeness, there currently are instances of `CalendarDate` and `TimeZone` required to represent a `Date`, so there's quite a bit...

Oh, wasn't aware of this one. Interesting.

Looks like, if `parseNamespace` is only used within `parseTopLevelStatement`, the code could be changed to obtain the identifier already in `parseTopLevelStatement`, passing it down to `parseNamespace` as an additional argument,...

Do you have an example of the additional parsing done by the transform? I think this would be useful to understand what's happening.

Conceptionally, however, the parsing stage would be complete once initialization happens. Anything after would have to modify the program directly. Or is the observation unrelated?

I wonder whether this is only applicable to `var`iables and `return`s. Another one that comes to mind is `throw`. Do you know what the spec says exactly for this case?...