BRPOPLPUSH return type is contingent on success about redis

[GoogleCodeExporter]

I agree that this should be consistent. Thanks for noticing.

The reason it is not right now is that it shares timeout code with the regular 
blocking pops, which in fact do emit a null multi bulk on timeout. In my 
opinion this is only cosmetic, since both the null bulk and null multi bulk 
means some kind of null value (unlike the empty bulk/string vs the empty multi 
bulk/array). Does the client you use return different objects for these two 
types of null replies?

Original comment by [email protected] on 30 Aug 2011 at 3:57

• Changed state: Accepted

[GoogleCodeExporter]

I've only used the redis-rb client before, which does return nil for any
null reply.

The reason I'm noticing the issue now is that I'm writing my own client in a
statically typed language, Haskell. Because of type inference and a mapping
that I define from Redis reply types to common Haskell types, if I declare
that my client's `brpoplpush` function returns the common type `IO (Maybe
String)` (i.e., a string that can be null), then it can be inferred at
compile time that a bulk reply should be read from the socket.

I worked around the BRPOPLPUSH issue by changing my type mapping so that `IO
(Maybe String)` can be coerced from either a bulk reply or a null multi-bulk
reply. However, having a guaranteed reply type for each command is a nice
property, and I figured that it would be worth pushing for if BRPOPLPUSH is
the only exception.

Original comment by [email protected] on 30 Aug 2011 at 8:54