As Marcelo pointed out, I did not Reply All; here is the email: On Tue, Jan 17, 2023 at 3:40 PM Zach Laine wrote:

On Tue, Jan 17, 2023 at 3:11 PM Marcelo Zimbres Silva wrote:

...

On Tue, 17 Jan 2023 at 20:39, Zach Laine via Boost wrote:

...

No. In particular, the API requires the user to write lots of Redis strings by hand. A typo will not be detected until runtime. The set of Redis keywords is fixed; there's no reason not to make an enumeration of them all, like this:

I had enums in the past but I had to remove them for a couple of reasons

1. There are a multitude of possible commands in the Redis stack, for example

* Redis search: https://redis.io/commands/?group=search * Redis graph: https://redis.io/commands/?group=graph * Redis time series: https://redis.io/commands/?group=timeseries * Redis json: https://redis.io/commands/?group=json * Perhaps more I might be missing righ now.

I don't yet see the problem. In the enumeration I made, there's a JSON_DEBUG (JSON.DEBUG from https://redis.io/commands/?group=json, but with s/./_/), etc. None of these enumerators collides with any other; I compiled the resulting enumeration to check exactly this. Am I missing something?

...

Then, we would probably agree that the command syntax is equally important. To check it properly I would have to write a generator that parses the description of each command and generates a checker, see https://github.com/redis/redis/tree/unstable/src/commands.

I have made no thoughts so far about how that would work and if I get that correctly I would still have to watch for versioning (what changes from release to release), what new commands were implemented and which were deprecated.

Yep. That's the job. The good news is that a new version need not be that disruptive. You only ever need to add to the enumeration, and you can add a single deprecation-detection function that compares any enumerator used against the list of enumerators that are deprecated.

...

That might be enough for Redis, but them I would be keeping other Redis-like databases off, for example

* https://github.com/Snapchat/KeyDB * https://github.com/scylladb/scylladb/blob/master/docs/dev/redis.md * https://github.com/dragonflydb/dragonfly * Perhaps more.

I don't know how compatible they are with the Redis API. I can't afford working on this right now and in the foreseeable future, I see it almost as a second library of a module of my library e.g. aedis::redis::search::request or something.

Ok, this is something different. If you don't want to break support for those other DBs, that's understandable. But since you don't have support for them at the moment, I don't think possibly adding support for those later (which could also be added in much the same way) should slow down adoption of a better interface for Redis today.

Zach