-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional members in cell paths: Attempt 2 #8379
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #8379 +/- ##
==========================================
- Coverage 68.06% 68.04% -0.03%
==========================================
Files 621 621
Lines 99885 99943 +58
==========================================
+ Hits 67988 68002 +14
- Misses 31897 31941 +44
|
Just to be clear, the reason you're suggesting we remove These produce identical results
and these produce identical results
If that is correct, then I'd propose dropping the |
Right, |
On second thought... removing
Removing the flag will break people's |
Oh! I just noticed that the If I remove it before the 0.77 release, that will make future deprecation of |
This is a follow-up from #8173, which was merged shortly after the 0.76 release. That PR changed `default_env.nu` so that the user's home folder is displayed as `~` in the left prompt. It did so using `get -i`. This PR just rewrites the Nu code from #8173 to use `try`/`catch` instead of `-i`, which will make it easier to remove the `-i` flags from `get` and `select` eventually (see #8379). I would like to merge this before the 0.77 release, so we don't end up with lots of `env.nu` files using `get -i` out in the wild.
I've removed the |
Thanks for revisiting this feature! |
I asked in Discord and several people voted to merge this. Let's give it a try! |
#8379 removed the `-i` flag from `get` and `select` because the new `?` functionality covers most of the same use cases. However, #8480 made me realize that `-i` is still useful when dealing with cell paths in variables. This PR re-adds the `-i` flag to `get` and `select`. It works by just marking every member in the cell path as optional, which will behave _slightly_ differently than `-i` used to (previously it would suppress any errors, even type errors) but IMO that's OK.
This is a follow-up to #8379 and #8502. This PR makes it so that the new `?` syntax for marking a path member as optional short-circuits, as voted on in the [8502](#8502) poll. Previously, `{ foo: 123 }.bar?.baz` would raise an error: ``` > { foo: 123 }.bar?.baz × Data cannot be accessed with a cell path ╭─[entry #15:1:1] 1 │ { foo: 123 }.bar?.baz · ─┬─ · ╰── nothing doesn't support cell paths ╰──── ``` Here's what was happening: 1. The `bar?` path member access returns `nothing` because there is no field named `bar` on the record 2. The `baz` path member access fails when trying to access a `baz` field on that `nothing` value After this change, `{ foo: 123 }.bar?.baz` returns `nothing`; the failed `bar?` access immediately returns `nothing` and the `baz` access never runs.
This is a follow up from #7540. Please provide feedback if you have the time!
Summary
This PR lets you use
?
to indicate that a member in a cell path is optional and Nushell should returnnull
if that member cannot be accessed.Unlike the previous PR,
?
is now a postfix modifier for cell path members. A cell path of.foo?.bar
means thatfoo
is optional andbar
is not.?
does not suppress all errors; it is intended to help in situations where data has "holes", i.e. the data types are correct but something is missing. Type mismatches (like trying to do a string path access on a date) will still fail.Record Examples
List Examples
Breaking changes
?
in them now need to be quoted.-i
/--ignore-errors
flag has been removed fromget
andselect
get
error handling can be done with?
and/ortry
/catch
.?
:We had some clever code that was able to recognize that since we only want row
0
, it's OK if other rows are missing columnb
. I removed that because it's tricky to maintain, and now that query needs to be written like:〉[{a:1 b:2} {a:3}].b?.0 2
I think the regression is acceptable for now. I plan to do more work in the future to enable streaming of cell path accesses, and when that happens I'll be able to make
.b.0
work again.