C API: Improve value initializers

[roberth]

Is your feature request related to a problem? Please describe.

Not having an EvalState here restricts the implementation of the C API to implementations of Nix that have a global garbage collector or equivalent; there's no reason to not take an EvalState that isn't used in the API for future proofing.

And, ignoring that, having the distinct argument ordering feels like it's a bit of a footgun.

--- #10537 (comment)

Describe the solution you'd like

Both issues follow from the format of the other initializers, but I'm not sure that it's a problem in this case, as the implementation doesn't allocate. Nonetheless, it's a risk, I suppose.

To be on the safe side, we could

* Change the argument order to put the out parameter last

* Add an `EvalState *`, which will be unused

* s/nix_init/nix_value_init? This is extra breaking, but that's actually helpful I think. The API is still in development, so that's ok.

--- #10537 (comment)

Describe alternatives you've considered

Additional context

Priorities

Add 👍 to issues you find important.

[puckipedia]

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 :))

[roberth]

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?

[puckipedia]

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.

[roberth]

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!