Edge case of where command

[blindFS]

The following code is valid in nu but causes error in tree-sitter-nu

[{a: {b: true}}, {a: {d: false}}] | where a?.b?

However the following code is not allowed in nushell

[{a: {b: true}}, {a: {d: false}}] | where a?.b? and a?.b?

Error: nu::shell::type_mismatch

  × Type mismatch.
   ╭─[entry #38:1:46]
 1 │ [{a: {b: true}}, {a: {d: false}}] | where a?.b? and a?.b?
   ·                                              ┬
   ·                                              ╰── expected bool
   ╰────

So which of the following way is suggested for its fix in tree-sitter-nu:

1. special treatment to make only the first case valid
2. allow both

[fdncred]

Seems like both of those should be where condition == true vs just where condition but maybe it's a bug in nushell?

[blindFS]

Seems like both of those should be where condition == true vs just where condition but maybe it's a bug in nushell?

I'm not sure, that usage is not present in the doc of where, but I've seen it somewhere in nu_scripts.

In my opinion, if we'd like to be able to save some effort when the column is itself a boolean, we should allow both cases.

Or simply don't allow any of those.

[fdncred]

I can understand that. I've asked the core-team what they think about it too.

[132ikl]

I think the problem here is the way the row condition shorthand is expanded, we only expand the shorthand on the left side. Like it might be confusing if where foo in bar checked where $it.foo in $it.bar rather than where $it.foo in "bar"

[blindFS]

I think the problem here is the way the row condition shorthand is expanded, we only expand the shorthand on the left side. Like it might be confusing if where foo in bar checked where $it.foo in $it.bar rather than where $it.foo in "bar"

I'm not sure I get your point, are you explaining that where a.b? and a.c? should be invalid because the RHS a.c? shouldn't get expanded?

I mean does it make any sense that and gets parsed as a binary op in a single "row condition" instead of one between 2 "row conditions"?

[132ikl]

that could make sense, I like that idea. I'm not totally sure how we would implement that though unless we had entirely bespoke parsing for row conditions. this is definitely something to keep in mind for new parser, if nothing else