Skip to content

first, take, last, skip, drop, take until, take while, skip until, skip while, where, reverse, shuffle, append, prepend and sort-by should error when given non-lists instead of coercing to list #6941

@webbedspace

Description

@webbedspace

Describe the bug

This is a continuation of #6764. After reporting that where implicitly coerces non-lists to list, I decided to see how many other commands have this issue. As it turns out, the relevant commands I could find are: first, take, last, skip, drop, take until, take while, skip until, skip while, reverse, shuffle, append, prepend and sort-by. There may be more, too.

Now, the sheer scope of this issue leads me to believe that list-based commands coercing-to-list was originally a Nushell de facto standard or such. I have a couple of arguments against it, which I would like to present now:

  1. Explicitly wrapping a non-list into a list is not hard

To make a known non-list value in a pipeline into a list, simply write [$in]. It's that easy. I will admit that currently, there's no really quick way of wrapping an unknown non-list value but not an existing list, apart from [$in] | flatten, but it's still possible. Having this kind of wrapping feature embedded, with no opt-out, in over a dozen commands is highly unnecessary.

  1. Masks errors

If something that should receive a list (and cannot do anything meaningful with a non-list) does not receive a list, then it should report an error as soon as possible. This is the basis of a useful type system - it helps the user quickly comprehend the meaning of the commands, and helps prevent mistakes when writing complicated pipelines. All of the commands above only have meaning when applied to lists.

  1. Promotes plain records into tables

This is a rather sharp corner for new users - it's difficult to tell the difference between records and one-row tables if you don't already know what one or the other "should" look like, and having a bunch of commands which convert one into the other if you use them improperly does not help matters in the slightest.

How to reproduce

〉2 | first 1
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | take 2
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | last 2
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | skip 0
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | drop 0
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | take until { false }
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | take while { true }
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | skip while { false }
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | skip until { true }
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | reverse
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | shuffle
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | append []
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | prepend []
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯
〉2 | sort-by foobar
╭───┬───╮
│ 0 │ 2 │
╰───┴───╯

Expected behavior

Errors for all of the above, due to being given 2 instead of a list.

Screenshots

No response

Configuration

key value
version 0.70.0
branch
commit_hash 9ef65dc
build_os windows-x86_64
build_target x86_64-pc-windows-msvc
rust_version rustc 1.64.0 (a55dd71d5 2022-09-19)
rust_channel stable-x86_64-pc-windows-msvc
cargo_version cargo 1.64.0 (387270bc7 2022-09-16)
pkg_version 0.70.0
build_time 2022-10-18 18:55:02 +00:00
build_rust_channel release
features database, dataframe, default, trash, which, zip
installed_plugins

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    notes:breaking-changesThis PR implies a change affecting users and has to be noted in the release notes

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions