// NOTE: We only unpack `either` errors that occurred *at the same level* as this error, ie. where there's directly a case of `either(either(...), ...)`, without any kind of data nesting (like `arrayOf` or `hasShape`) inbetween. Nested-data failures should still be shown separately, as their resolution strategy is actually different; unlike same-level nested `either` errors, where the nesting is purely an implementation detail that allows composing sets of alternatives together.
thrownewError(`Must specify an array of alternatives`);
}elseif(alternatives.length<2){
// This doesn't interfere with conditionally-specified alternatives using ternary expressions, because in those cases there is still *some* item specified, it's just going to have a value of `undefined` (and will subsequently be filtered out)
thrownewError("Must specify at least two alternatives");
}elseif(arguments.length>1){
thrownewError(`Only one argument is accepted; maybe you forgot to wrap the different alternatives into an array?`);
// We want to immediately stop trying alternatives when a non-ValidationError occurred, since that means that something broke internally somewhere, and it is not safe to continue executing.
// One of the alternatives *did* match, but it failed somewhere further down the tree, and we don't have any errors originating from *other* nested rules. Chances are that the user intended to match the failing branch, so we pretend that the other alternatives don't exist, and pass through the original error(s).
returnvalidationResult({errors:nestedErrors});
}else{
// Somewhere, possibly nested inside of a "must satisfy all", we've seen errors at varying subpaths. This means that the user probably tried to match some sort of arm, but we don't know which, because the origins are not identical. Therefore we will just remove all the top-level errors, and only show the ones that are at *some* sort of sub-path.