Note that with this change in place you can't distinguish [] from [null] with last - you have to check for list length now. Previously, the following would have worked:

[null] | try { last } catch { print "empty" }

and now it will need to be

[null] | if ($in | is-not-empty) { last } else { print "empty" } # will also collect, because of $in

whereas previously the default could still be used on empty lists like this:

[] | try { last } | default "n/a"

but now you can do this, no try needed

[null] | last | default empty
empty
[] | last | default empty
empty

If you didn't care about null elements of the list, you could do

[] | default -e [null] | last
# or 
[] | default -e [empty] | last

But if you do care, you now can't tell if it was the last element that was null or if there were no elements at all (without an explicit length check).

But if you do care, you now can't tell if it was the last element that was null or if there were no elements at all (without an explicit length check).

I'm not trying to be rude, but why do I care to know if the last element was null or no elements at all. The point is to use it easily with default and replace what was there with a default value.

BTW - I'm fine with changing this as long as it works the same way it does now. e.g. we can add parameters to default or first/last but I think the way this PR changes things should be the default way it works.

why do I care to know if the last element was null or no elements at all.

If we follow that logic, then [] should be equal to [null], but it's not the case. You may want to care if the list (or stream) represents the results of some operations, where each individual operation may result in null (for example, processing a list of files), and you want to handle the case where there were no operations at all (no files found) differently to when the last/first operation resulted in null.

Previously, you had the option to do try { first } | default "n/a" (which I find very clear and expressive) if you didn't care about nulls / errors, or try { first } catch { handle the error } if you wanted to handle the empty list/stream case, but not the null case, or just first if you wanted the error to bubble up. There were multiple ways to handle different cases, depending on what you need. Now that the output domain of these functions is narrowed, that choice is gone, or, at the very least, will have to be done in a different place with a different method (length checks?).

I'm fine with changing this as long as it works the same way it does now.

If you mean 'now' as in 'on current main', that sounds a bit contradictory ("it's ok to change as long as nothing changes").

we can add parameters to default or first/last

What kind of parameter do you have in mind? Opt-in to null return on out-of-bounds read (e.g. first --optional, similar to get --optional), or opt-in to errors on out-of-bounds read (first --strict, like path expand --strict)?

What kind of parameter do you have in mind? Opt-in to null return on out-of-bounds read (e.g. first --optional, similar to get --optional), or opt-in to errors on out-of-bounds read (first --strict, like path expand --strict)?

Let's try to add --strict to first and last command