Ensure nil safety of builtin functions that accept interface or pointer arguments

[xiaq]

What happened, and what did you expect to happen?

#1869 reported an issue where flag:parse doesn't handle nil arguments properly, but there are probably many more builtin functions that need to be fixed and it''s probably quite annoying to fix all of them.

Maybe conversion of Go values to Elvish values should reject nil by default, with some special annotation that allows nil. For example, using a hypothetical annotation syntax:

func f(a vals.List) {
    // this function, when used as an Elvish builtin, doesn't accept nil
}

func g(a @Nilable vals.List) {
    // this function, when used as an Elvish builtin, accepts nil
}

Not quite sure how @Nilable would be implemented with actual Go language features though. One way for this to work syntactically is to define Nilable as a generic wrapper type:

type Nilable[T any] struct {
    Inner T
}

Calling Go functions from Elvish uses reflection, so whether this would work depends on whether we can reliably tell that a runtime concrete type Nilable[T] is actually an instance of Nilable.

Output of "elvish -version"

irrelevant

Code of Conduct

• I agree to follow Elvish's Code of Conduct.