Should there be an `impl<T: AllocValue> AllocValue for Option<T>`?

[Adam Perry]

I have this helper function that seems like it should maybe be a trait impl:

fn opt_typed_val<'h>(heap: &'h Heap, v: Option<impl AllocValue<'h>>) -> Value<'h> {
    if let Some(v) = v {
        heap.alloc(v)
    } else {
        Value::new_none()
    }
}

Are there any risks to supporting this kind of automatic conversion? I haven't been able to think of situations where you'd want a different encoding of Option<T> but I could easily be missing something.

[Neil Mitchell]

The disadvantage is there is no corresponding UnpackValue for Option, and there shouldn't really be, as Option is treated as a missing parameter for UnpackValue, rather than an optional. I find the encoding of None as Option::None in Python/Starlark a bit curious. E.g. you can't compare None values, and if people encoded them as Option::None, you'd expect to be able to with None being less than other values.

That said, while it's not symmetric with UnpackValue, I can't think of anything else that AllocValue Option<T> might do other than what you've written above. Of course, if you do AllocValue of Option<Option<String>> then you lose the information, which is a bit of a shame.

So that's two reasons to be a bit reluctant to add this type more generally. Thoughts?

[Neil Mitchell]

This got added a few years ago, so exists now. Not quite sure when.