Reflections on Serialization APIs in D

[Orvid King]

On 11/18/13, Atila Neves <atila.neves at gmail.com> wrote:
>> I would suspect that the biggest reason is the limitations that
>> that
>> imposes on the underlying serialization implementation, as it
>> would
>> require that the underlying format support a minimum set of
>> types.
>
> I'm not sure that's actually true. I've been working on my own
> serialisation library in D that I plan to unleash on the announce
> forum soon and it does it in a manner described by the original
> poster. Even with custom serialisations, client code need only
> define one function for both directions.
>
> The only reason I haven't announced it yet is because I wanted to
> be pure it's polished enough, but maybe I shouldn't wait.
>
> Atila
>

I am curious as to how exactly that would work, does it determine the
output format at compile-time or runtime? Does it specify the way it's
serialized, or it's serialized representation? I'd also be curious
about the performance impact it brings, if any. Depending on it's
exact function it's perfectly possible that it could actually be
faster than my toString/parse combo because mine requires the string
be allocated from toString, due to the lack of knowledge of the
underlying format.