mirror of
https://github.com/nushell/nushell.git
synced 2025-05-07 00:12:58 +00:00
1be4eaeae3
In my view we should revert nushell/nushell#8395 for now ## Potentially inconsistent application of semantic change #8395 (1d5e7b441b9564b7ee9fe822d908b20fbf4b8682) was loosening the type coercion rules significantly, to let missing data / void returns that were either expressed by `PipelineData::Empty` or the `Value::nothing` be accept by specifically those commands/operations that made use of `PipelineData::into_iter_strict()`. This could apply the new rules inconsistently. ## Turning explicit failures into silent continuations Furthermore the effect of this breaking change to the missing data semantics could make previous errors into silent failures. This could either just reduce the effectiveness of teaching error messages in interactive use: ### Contrived example before ```bash > cd . | where blah Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #13:1:1] 1 │ cd . | where blah · ──┬──┬ · │ ╰── input type: null · ╰── only list, binary, raw data or range input data is supported ╰──── ``` ### ...after, with #8395 ```bash > cd . | where blah ╭────────────╮ │ empty list │ ╰────────────╯ ``` In rare cases people could already try to rely on catching an error of a downstream command to actually deal with the missing data, so it would be a breaking change for their existing code. ## Problem with `PipelineData::into_iter_strict()` Maybe this makes `_strict` a bit of a misnomer for this particular iterator construction. Further we did not actively test the `PipelineData::empty` branch before  ## Parsimonious solution exists For the motivating issue https://github.com/nushell/nushell/issues/8393 there already exists a fix that makes `ls` more consistent with the type system by returning an empty `Value::List` https://github.com/nushell/nushell/pull/8439