Cusom command: default value shouldn't restrict argument's type

[WindSoilder]

Describe the bug

Notice that when we define a custom command's argument with default value, the type of argument will be bounded.

How to reproduce

Run the following script:

def a [b: any = null] { print ($b == null) }
a 3

Then nushell throws the following error:

Error: nu::parser::parse_mismatch_with_full_string_msg

  × Parse mismatch during operation.
   ╭─[entry #16:1:1]
 1 │ def a [b: any = null] { print ($b == null) }
 2 │ a 3
   ·   ┬
   ·   ╰── expected nothing
   ╰────

Expected behavior

I expected nu to print false

Screenshots

No response

Configuration

key	value
version	0.84.1
branch	main
commit_hash	715c157
build_os	macos-x86_64
build_target	x86_64-apple-darwin
rust_version	rustc 1.70.0 (90c541806 2023-05-31)
rust_channel	stable-x86_64-apple-darwin
cargo_version	cargo 1.70.0 (ec8a8a0ca 2023-04-25)
build_time	2023-08-29 16:48:30 +08:00
build_rust_channel	release
allocator	standard
features	default, extra, sqlite, trash, which, zip
installed_plugins

Additional context

No response

[WindSoilder]

Should the following two things behave differently?

def a [b: any = 3] { print ($b | describe) }
def a [b = 3] { print ($b | describe) }

Currently, they all bound the type of $b to int.

I think in the first case, the type of $b should be any, because we define it explicitly.
For the second one, it can be int, because we don't define the type, so the type can be inferred by default value

[amtoine]

@WindSoilder
my two 🪙, i think

def a [b: any = 3] { print ($b | describe) }
a "foo"

should definitely work because both 3: int and "foo": string are of type any 👍