Unit type fallback lint in nightly

[stepantubanov]

This isn't a bug report. There's a new lint that was recently added: dependency_on_unit_never_type_fallback (see https://github.com/rust-lang/rust/issues/123748) and it triggers for fred calls that do not explicitly specify return type.

For example:

conn.set("key", "value").await?;

will trigger it because return value is implicitly ().

It can be avoided by changing code to:

let _: () = conn.set("key", "value").await?;
// this also works:
conn.set::<(), _, _>("key", "value").await?;

I wonder if there's a way to address it in fred without changing all the call sites to explicitly specify unit return type?

[mrjackwills]

With the release of Rust 1.81.0, this lint is now on by default. I know it can be ignored, with #[expect(dependency_on_unit_never_type_fallback)], but by the looks of it, things will not compile when Rust 2024 gets released.

I am not entirely sure the solution would be - else I'd submit a PR, but I'll have a play around and see if I can formulate anything, in the mean time the solutions listed above work.

[aembke]

There's a long thread about this in this redis-rs repo, and a link to a discord discussion with more info: https://github.com/redis-rs/redis-rs/issues/1228

Unfortunately I don't think there really is a solution to this. It sounds like the use case of functions that have side effects with generic return values that can be conditionally ignored is just not well supported by the current type system.

The partial workaround that redis-rs used was to expose a new function without any generics that can be used when callers don't care about the result.

[mrjackwills]

Thanks, I probably agree with this comment, the let _: () verbose solution seems to be working for me, so I guess that's just the easiest fix.

[maxcountryman]

Thanks, I probably agree with this comment, the let _: () verbose solution seems to be working for me, so I guess that's just the easiest fix.

Sorry I'm not able to see the link behind that comment you've linked to, but are you saying that in application code we should annotate thusly to avoid this? (This is currently breaking some of my crates that depend on fred.)

[aembke]

Yeah, you'll want to use the let _: () = ... or client.get::<(), _, ...>(...) syntax to avoid this. In case it helps, the first generic argument is always the response so you can usually just use placeholders for all the others when using turbofish.