Unsafe API about laserdisc

[sirocchj]

/cc @barambani @fiadliel @nicodom I'd like to collect your thoughts on this.

My current belief is that this could easily open up the can of worms for anyone to abuse of this "feature" but otoh it would also facilitate the adoption.. As in, we're not pushing the burden all the way to the end user - who'd have to take full responsibility for having to explicitly write code that would be unsafe to satisfy laserdisc's constraints - but we're "easing" the adopter's pain of integration into existing unsafe code by allowing an escape hatch where this unsafe code is the same for everyone and provided by laserdisc itself

[barambani]

My 2c. As discussed recently in a couple of real life examples, I think there's no reason to relax the constraints on the keys (being non empty for a single key or being non empty list of keys for a group). The decision of what to do at runtime in case the key is empty is actually easier if it's pushed all the way up to the place where this key is generated from the string (usually a deserialisation from a text format if it's at runtime). Mainly the question there is what to do in that case. It can also be that the user might want to throw an exception, but I think we shouldn't help her in that. Sending a command to Redis with an empty key is never correct, so IMHO it should never be allowed by the type.