Discuss: question mark operator

Related problem

This is a discussion issue around how, if desired, a question mark operator should work in the nu language. There are two main motivations behind this:

1. to allow more ergonomic error handling as opposed to try.
2. to provide a unified way for handling errors.

Regarding 2., some commands are strict and can be expected to error (e.g., the first and into family of commands). This is why get has the -i option. But rather than adding a -i flag to each of these commands, a question mark operator would provide a standard method for ignoring errors from any command.

Describe the solution you'd like

One proposal is that the question mark operator would serve as a shorthand to try. If a value or expression is not an error, it is returned. Otherwise, the question mark operator returns null.

So, the following two would be equivalent:

[] | try { first }
[] | first? 

And the same for these two examples:

try { [a] | into int | first }
([a] | into int | first)?

But since this adds no functionality over try and is simply syntactic sugar, another possible solution is to have ? return a boolean. The use case here is to detect whether or not an internal or external command failed:

# `?` with an error returns `false`,
# otherwise `true` is returned.

# can be read as: if this did not succeed
if not (mkdir "test")? {
  # print an error or do some other logic
}

# can be read as: if this succeeded
if (mkdir "test")? {
  # ...
}

This kind of check would not be possible with the first solution that returns null, since mkdir also returns null.

Then, this can be extended to test the exit code of an external command:

if (^false)? {
  # zero exit code
} else {
  # non-zero exit code 
}

One potential issue is that ? is already used for optional cell paths where null is returned if the path does not exist. So, this may be inconsistent or confusing with this second solution that returns a boolean.

Describe alternatives you've considered

No response

Additional context and details

Related: #11460

Start by reading the proposal and the related issue #11460, then review the discussion about error handling, null values, booleans, external command exit codes, and optional cell paths. The work is not ready to implement until the behavior of the question mark operator is decided and the intended syntax and semantics are documented.