C API: Improve value initializers about nix HOT 4 OPEN

I'm not sure that it's a problem in this case, as the implementation doesn't allocate

The issue with this statement is that this is an implementation detail. It's not guaranteed to be the case over alternative Nix implementations, or even changes to the existing implementation, which is what the C API is designed to avoid.

(Tbh, re #10499, having a distinction between thunked and non-thunked feels a bit iffy to me as well, because this is harder to abstract over in other languages; it'd feel more comfortable personally to have the entire API re-thunked instead of adding more bits and pieces on top. It's unstable for a reason :))

from nix.

The issue with this statement is that this is an implementation detail.

That's fair, but I'm having trouble to imagine an implementation that would allocate in an initialization routine. I suppose this would involve some serious "adapter" logic to bridge a significant mismatch between the memory model of an alternate implementation and a memory model that's close to what the C API suggests.
Out of curiosity (as I agree), do you have a concrete situation like that in mind, or are we just managing the risk?

alternative Nix implementations

This is not an explicit goal, though I would like for this to work as well as it can.

Tbh, re #10499,

I'm ok to discuss here, but might be more effective to comment there.

By "re-thunked", do I understand correctly that you agree with the goal of having more lazy behavior, and also wish to remove the functions or behaviors that are unnecessarily strict?

from nix.

That's fair, but I'm having trouble to imagine an implementation that would allocate in an initialization routine

I'd counter that "applying an argument to a lambda/callable" is, in fact, not strongly an "initialization routine", and doesn't nix_init_string allocate as well?

alternative Nix implementations
This is not an explicit goal, though I would like for this to work as well as it can.

As I said, "or even changes to the existing implementation." - there's no guarantee this may change in the future with a better interpreter.

By "re-thunked", do I understand correctly that you agree with the goal of having more lazy behavior, and also wish to remove the functions or behaviors that are unnecessarily strict?

Having one set of functions that are all lazy, rather than a set that is lazy and a set that is strict, is my preference; but I can see reasons for wanting both.

from nix.

The purpose was to initialize an already allocated value to be a thunk. Laziness requires that that's a simple operation, but non-strictness does not. I suppose an evaluator might want to be more eager in some cases? I don't think a requirement to have both the simple and eager behavior would be a burden on evaluators, but I'll cut it short here because I already agreed, and I think we've found a potential concrete reason - even better.

Thank you for the discussion and clarification!

from nix.