Is there a way to restrict a generic argument so that it cannot be an iterable value?

Perhaps something like below?

where T: !IntoIterator

Negative bounds are unstable and will in the future before stabilizing AIUI likely require an explicit negative impl to avoid new impls from breaking code.

Why do you want this?

Ok thanks so not possible as of right now.

Stumbled onto this issue and am trying to fix it: The hset API does not work as envisioned when dealing with vectors/list types · Issue #853 · redis-rs/redis-rs · GitHub

Looks like unintended fallout from this decision.

Thanks. Just wondering, any tips on how to fix this if negative bounds do not yet exist in Rust?

Hmm. You could perhaps have a ToSingleRedisArg trait for the ones that act like you want for hset, and then have a blanket implementation

impl<T: ToSingleRedisArg> ToRedisArgs for T { /* ... */ }

If it makes sense, ToRedisArgs could also be a supertrait of ToSingleRedisArg. But if you want &[T] to implement ToSingleRedisArg (by acting differently from ToRedisArgs), the supertrait probably doesn't make sense.

(I didn't deep dive on the repo, so I'm not sure how applicable this possibility is.)

2 Likes

It doesn't seem like a negative bound is the proper solution to this. That would basically be a hack that would "fix" one single, low-level problem in this specific case, and likely cause other issues elsewhere. The real solution would be to correct the implementation of redis-rs so that it doesn't randomly mix up keys and values.

1 Like

Right now the way to get around this bug as a user is to serialize the vector into a string via serde before invoking the HSET command.

If this string serialization process is implemented so that the crate automatically does it for you, would you consider this a hack or a viable fix?

First time doing open source so appreciate all the help!

Serializing to a string still doesn't feel like a proper solution, although it certainly is more general and less weird than negative trait bounds.

What exactly prevents the crate author from fixing the root cause?

Thanks for the advice. Regarding your question, I think that this crate is mainly maintained by a few Rust enthusiasts which is why new issues may not be addressed in a timely fashion.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.