GitLab

Easier than previous commit message seemed to think.

Since we already have finishCallback functions in play in any scene
where maybes can also be in play, we can just make those responsible
for copying out a pointer from the child assembler to the parent value.
That makes the child assembler able to create a new value late in
its lifecycle and still expect it can land in a proper home.

Tests needed badly; this is *oodles* of edge cases.
Unrelated fix needed first.  (Might make that elsewhere and rebase
this to include that, to reduce the carnage ever so slightly.)

Fix many issues with maybes; adjunct config for if maybe is implemented using a pointer; attempt the finishCallback system for reusable child assemblers.

This... almost appears to be on a dang nice track.

Except one fairly critical thing.  It doesn't work correctly if your
maybe IS implemented as containing a pointer.

Because that pointer starts life as nil in the parent structure.

And that's hard to fix.

We can't have a pointer to a pointer in the assembler;
that'd cause the type bifructation we've been trying to avoid.
(We can give up and do that of course; it would be correct.
Just... more code and larger final assembly size.
And if we did this, a lot of this diff would be rewritten.)

We could have the parent structure allocate a blank of the field,
and put a pointer to it in the maybe and also in the child assembler.
Except... this is a wasted allocation if it turns out to be null.

Rock and hard place detected in a paired configuration.
Might have to back out of this approach entirely.  Not sure.

We'll see how this works out.

Lots of tasty bitshuffling in this commit.

Remaining: creating, embedding, and returning child value assemblers.
This might involve a full type per field: doing so would be direct,
have pretty excellent verbosity in debugging symbols,
and pointers back to parent suffer no interface indirection;
overall, it's probably going to have the fastest results.
However, it would also mean: we can't save resident memory size if we
have more than one field in a struct that has the same type;
and we we can't avoid increasing binary size if the same types are used
as fields in several places.
Going to pause to think about this for a while.

This cleans up a lot of stuff and reduces the amount of boilerplate
content that's just generating monomorphizing error method stubs.

The nodeGenerator mixins now also use the node mixins.  I don't know
why I failed to do that from the start; I certainly meant to.
It results in shorter generated code, and the compiler turns it into
identical assembly.

Compiles and runs; but the results don't.
Some small issues; some big issues.  Just needed a checkpoint.

It's feeling like it's time to deal with breaking down the assembler
generators in the same way we did for all the node components, which
is going to be kind of a big shakeup.

I *think* the notes on Maybes are now oscillating increasingly closely
around a consistent centroid.  But getting here has been a one heck of
a noodle-scratcher.