Reconsider thunks in `ValueType`

[Radvendii]

There's some weirdness in the C API when it comes to thunks. They are sort of just considered normal values, but most of the time they are forced before being returned from functions, and for some purposes you don't want to consider them normal values.

We discussed a couple of options for redesigning this, including

• Having two enums, one with one without thunks
• Using something like trees that grow. This adds a lot of complexity though
• Using an enum without thunks, and then an Option<T> to represent thunks (None being "it's a thunk") The function returning this value could be something like type_if_evaled(&Value): Option<ValueType>
• Once a value is forced, it can maybe be a nicer enum, such that there's no possibility of trying to get the string value out of an int value.

Another point related to this restructuring: perhaps force() should take a &mut self, since it might mutate the underlying value.

[roberth]

• Using an enum without thunks, and then an Option<T> to represent thunks (None being "it's a thunk") The function returning this value could be something like type_if_evaled(&Value): Option<ValueType>

I've merged this option. (#42 into nixops4/nixops4#18)

perhaps force() should take a &mut self, since it might mutate the underlying value.

It seems like a good idea, but we can't prevent two Value from aliasing the same underling Nix value, so we don't get real protection from this.
I guess we could still use it to communicate intent, but that still comes with a risk of just getting in the way.

[Radvendii]

We can't prevent two Value from aliasing the same underling Nix value

Yes we can, since we're the only ones producing Values, right? We have to be careful never to alias internally in the library, but the intended public API does not provide a way for the user to produce two Values pointing at the same Nix value, does it?

[roberth]

we're the only ones producing Values, right?

That's correct for the Rust Value, but those are ultimately nothing more than pointers to nix::Values, which Nix will happily alias for us. Consider:

let attrs = eval_from_string("{ a = { b = foo bar; }; }", "<test>")?;
let a0 = require_attrs_select(attrs, "a")?;
let a1 = require_attrs_select(attrs, "a")?;

a0 and a1 are distinct Rust Values, but both are pointers to the same nix::Value containing { b = foo bar; }.

[Radvendii]

Okay, so this is unfortunate but not as catastrophic as I was initially imagining. Because we're only ever dealing with the c/raw pointer in rust code, and never converting it into a reference. We take a reference to the rust object that contains it, but that's different. Therefore, rust never assumes its borrow checker rules hold. I don't think it will ever pass e.g. noalias to llvm and run us up against undefined behaviour.

So this isn't going to trip up the compiler, just potentially programmers who think a &Value won't change randomly from under them.