Is there a way to define a record field as opaque while using deriving bin_io? The functionality would be similar to sexp_opaque (e.g., https://realworldocaml.org/v1/en/html/data-serialization-with-s-expressions.html), i.e., serializers would work as normal, but deserialization would fail.
I looked into ppx_bin_prot a bit, but couldn’t find something that has the same effect.
We don’t have exactly that, and indeed, I wonder what you would use it for. What’s the point of writing out bin-io that you can’t read back in at all? With s-expressions, at least, you end up with a human readable representation of the data; but with bin-io, the whole thing seems kinda pointless if you can’t read it back…
Thanks for the reply!
We don’t have exactly that
What is the closest thing to this that exists? I already found a workaround - it’s currently based on polluting the codebase with dummy wrappers - but it seems this would be something simple to add and potentially useful?
I wonder what you would use it for.
It’s mostly about rapid prototyping and quickly meeting a library interface when you’re not using all its features. To be more concrete: consider a library that allows you to build a bunch of infra on top of a datatype, including: pretty-printing, caching, serialization, operator shorthands etc, but it requires your datatype to have bin_prot serializers (among other things). If you are never really going to use the serialization features, having an opaque construct would help you achieve this faster.
One could say “then don’t use that library” or “fix that library” and I would agree that’s a reasonable option long-term, but sometimes you need a solution “now”. Does that make sense? I think an “opaque” construct would be useful in cases like the one I described above.