I was looking at the Elvish source to see if there was an established abstraction for returning multiple errors. Yes, there is a multiple error abstraction. That caused me to notice the multi-error builtin command that is undocumented. So I'm opening this issue to remind the developers to either document the command or remove it.
P.S., There is also no support for introspecting the multiError type; only conversion to a string. There is also incomplete support. The builtin multi-error command produces a PipelineError object. However, a errutil.multiError returned by a builtin function is a different type not understood by the repr machinery. It's also not clear that the PipelineError abstraction is necessary; or that its name best reflects its semantics if we decide to retain the multi-error builtin.
P.P.S., After a few more minutes reflection it seems to me the PipelineError type should be folded into the MultiError type. That would resolve all of the issues and the name reflects the fact that there can be situations that return multiple errors (e.g., the undocumented multi-error builtin) that do not involve command pipelines in the sense meant by the current PipelineError type.
I was looking at the Elvish source to see if there was an established abstraction for returning multiple errors. Yes, there is a multiple error abstraction. That caused me to notice the
multi-errorbuiltin command that is undocumented. So I'm opening this issue to remind the developers to either document the command or remove it.P.S., There is also no support for introspecting the
multiErrortype; only conversion to a string. There is also incomplete support. The builtinmulti-errorcommand produces aPipelineErrorobject. However, aerrutil.multiErrorreturned by a builtin function is a different type not understood by the repr machinery. It's also not clear that thePipelineErrorabstraction is necessary; or that its name best reflects its semantics if we decide to retain themulti-errorbuiltin.P.P.S., After a few more minutes reflection it seems to me the
PipelineErrortype should be folded into theMultiErrortype. That would resolve all of the issues and the name reflects the fact that there can be situations that return multiple errors (e.g., the undocumentedmulti-errorbuiltin) that do not involve command pipelines in the sense meant by the currentPipelineErrortype.