Unsafe API

[sirocchj]

In many circumstances, as much as we'd like it to be, creating a safe protocol that is verifiable at compile time is just not possible.

One example would be when the Key needed in a get has to be constructed at runtime (say by appending together other string only available at runtime by consuming some external source).

In all these circumstances we may feel that the burden of having to prove the compiler we have valid Keys is just too big and what we really wish for is a good ol' RuntimeException, something that would just make us feel at peace with the universe...

I'm thinking something like:

trait UnsafeStringP { self: StringP =>
  final def get[A](key: String)(
      implicit ev: NonNullBulkString ==> A
  ): Protocol.Aux[Option[A]] = {
    require(key.nonEmpty, "why are you doing this to me now")
    self.get(Key.unsafeFrom(key))
  }
}

I'd also love to see this properly packaged under some very comforting namespace like hell or blinded (which I personally like a lot 'cause it plays well with laserdisc, i.e. import laserdisc.blinded._)

[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.