Fix Option<&str> == Option<&String> build error when using rust_decimal/rkyv feature

[dtolnay]

Without this change, projects which depend on both nu-command and rust_decimal's "rkyv" feature cause nu-command to fail to compile.

[dependencies]
nu-command = { path = "../nushell/crates/nu-command" }
rust_decimal = { version = "1", features = ["rkyv"] }

error[E0277]: can't compare `std::option::Option<&str>` with `std::option::Option<&std::string::String>`
   --> nushell/crates/nu-command/src/filters/join.rs:367:35
    |
367 |         let k_shared = shared_key == Some(k);
    |                                   ^^ no implementation for `std::option::Option<&str> == std::option::Option<&std::string::String>`
    |
    = help: the trait `PartialEq<std::option::Option<&std::string::String>>` is not implemented for `std::option::Option<&str>`
    = help: the following other types implement trait `PartialEq<Rhs>`:
              <std::option::Option<Box<U>> as PartialEq<rkyv::niche::option_box::ArchivedOptionBox<T>>>
              <std::option::Option<T> as PartialEq>
              <std::option::Option<U> as PartialEq<rkyv::option::ArchivedOption<T>>>

For more information about this error, try `rustc --explain E0277`.
warning: `nu-command` (lib) generated 1 warning
error: could not compile `nu-command` (lib) due to previous error; 1 warning emitted

[AucaCoyan]

This looks all good, thanks!

[sholderbach]

The change making this explicitly symmetrical sounds good.

Surprised that this is the only place in the code base where this PartialEq type coercion problem pops up.

= help: the trait `PartialEq<std::option::Option<&std::string::String>>` is not implemented for `std::option::Option<&str>`
    = help: the following other types implement trait `PartialEq<Rhs>`:
              <std::option::Option<Box<U>> as PartialEq<rkyv::niche::option_box::ArchivedOptionBox<T>>>
              <std::option::Option<T> as PartialEq>
              <std::option::Option<U> as PartialEq<rkyv::option::ArchivedOption<T>>>

Do I read that message correctly that if those other types are not visible (we don't use them) the T in impl PartialEq<Option<T>> for Option<T> takes impl PartialEq<String> for str.

[dtolnay]

The standard PartialEq impl for Option only applies to Option<T> == Option<T>. There is never a situation in which impl PartialEq<String> for str would come into play.

[sholderbach]

I am even more confused how this compiled fine before but not with rkyv. But my understanding of Deref coercion outside fns with specified target types is not really principled and more a gut feeling.

There is never a situation in which impl PartialEq<String> for str would come into play.

Right, T in a generic may be opaque but always a single concrete type.

[dtolnay]

shared_key's type is Option<&str>. If the 2 non-standard-library PartialEq impls shown in the error message (PartialEq<ArchivedOption<T>>, PartialEq<ArchivedOptionBox<T>> are not part of the program, then the unique impl which could apply in shared_key == ?? is PartialEq<Option<&str>>. So shared_key == Some(k) coerces k (which is &String) to &str using Deref coercion.

When there are other possible PartialEq impls that could apply, the coercion won't happen.

[dtolnay]

FYI @djkoloski. I am not familiar with rkyv so I don't know what impact on the API this would have, but I would recommend looking into removing the PartialEq impls linked above if possible. See also serde-rs/json#380 — we have found that PartialEq in this direction (standard_type == my_type) causes more problems than they are worth.