Require that values that look like numbers parse as numberlike

[sophiajt]

Description

Require that any value that looks like it might be a number (starts with a digit, or a '-' + digit, or a '+' + digits, or a special form float like -inf, inf, or NaN) must now be treated as a number-like value. Number-like syntax can only parse into number-like values. Number-like values include: durations, ints, floats, ranges, filesizes, binary data, etc.

User-Facing Changes

BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE

Just making sure we see this for release notes 😅

This breaks any and all numberlike values that were treated as strings before. Example, we used to allow 3, as a bare word. Anything like this would now require quotes or backticks to be treated as a string or bare word, respectively.

Tests + Formatting

Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

• cargo fmt --all -- --check to check standard code formatting (cargo fmt --all applies these changes)
• cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect to check that you're using the standard code style
• cargo test --workspace to check that all tests pass

Note
from nushell you can also use the toolkit as follows

use toolkit.nu  # or use an `env_change` hook to activate it automatically
toolkit check pr

After Submitting

If your PR had any user-facing changes, update the documentation after the PR is merged, if necessary. This will help us keep the docs up to date.

[fdncred]

It seems odd to me that we cannot detect that these examples below are not numbers considering we can detect that 3+1 doesn't work but 3 + 1 does. We also detect that 1_000_000 is a number, and any of these typed in the repl is not a number. Seems like looking ahead for non-number chars after a number would disqualify it from being a number. Maybe it's not that simple?

1.0.0
1f378
3,
10/12/2013

Is there any hope of making this work in the future?

[sophiajt]

@fdncred the focus of the PR is to not try to detect if they are a number or not. The main reason is that to the reader may not have the full context of the allowed values of Nushell in their head, so they may make assumptions. For example, looking at the ones you mention:

1. Looks like a version number, but is a string
2. Looks like a hex number, but is a string
3. Looks like the number 3 followed by comma, but is a string
4. Looks like a date, but is a string

I think all the examples you showed are confusing to the reader as they all look like they are number-like values but instead are strings.

[ineu]

While this might be a good decision for programming in Nu, it's very inconvenient for a shell. It's very common to pass strings that look like numbers as arguments to programs. A good example is program versions, especially those following the semantic versioning: https://semver.org
I have the following script that used to work before but doesn't work any longer (especially given that I explicitly set type of the version argument to string):

# chruby.nu
# ...
export def-env main [ version?: string@list-installed ] {
# ...
}

The purpose of the script is to set the ruby version in the shell. I could call it like this:

chruby 3.2.1
chruby 3.2
chruby 3

but none none of the variants work. What works is

chruby "3.2.1"
chruby "3.2"
chruby "3"

But forcing a user to always wrap values into quotes is a terrible shell experience. A shell is all about speed and convenience after all.

[Deebster]

I'm also not enjoying this feature. I've already hit this Error: nu::parser::parse_mismatch false positive several times today while trying to pass arguments to (different) programs/commands such as 2m30s and 10km, as well as the version that @ineu brought up.