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
Nushell core libraries and plugins
These sub-crates form both the foundation for Nu and a set of plugins which extend Nu with additional functionality.
Foundational libraries are split into two kinds of crates:
- Core crates - those crates that work together to build the Nushell language engine
- Support crates - a set of crates that support the engine with additional features like JSON support, ANSI support, and more.
Plugins are likewise also split into two types:
- Core plugins - plugins that provide part of the default experience of Nu, including access to the system properties, processes, and web-connectivity features.
- Extra plugins - these plugins run a wide range of different capabilities like working with different file types, charting, viewing binary data, and more.