My point is that serializing POD-based structures in D is so
simple that
using a one-size-fit-all serializer made to handle absolutely
everything
feels very wasteful.
You don't have to use it.
But I do use it, quite a bit. Whenever I have any form of
polymorphic serialization, Orange is excellent. I find myself
effectively choosing between two serialization libraries based on
my needs right now, which is actually a very good thing.
The issue here is not whether I should be using Orange or not in
a given project, but whether it should become std.serialization.
If that happens, then I will find myself "forced" to use it, the
same way I should be "forced" to use std::vector in C++ unless I
am dealing with a truly exceptional situation.
But serializing data to send on a socket efficiently should NOT
be treated as an exceptional case. If anything, I think it should
be the base case. If/When std.serialization exists, then it will
effectively become the goto serialization mechanism for any D
newcomer, and it really should handle that case efficiently and
elegantly IMHO.
I will grant that making Orange part of Phobos will alleviate the
project bloat issue, which is a huge deal. But as it stands, to
me, it only handles a subset of what std.serialization should.
