On 2013-11-18 16:11, Atila Neves wrote:

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

Is that only for custom serialization or a general requirement?

-- 
/Jacob Carlborg

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

I promise to announce and explain it soon. Maybe even today. I just have to fix one small detail.

On Monday, 18 November 2013 at 15:26:28 UTC, Jacob Carlborg wrote:
> On 2013-11-18 16:11, Atila Neves wrote:
>
>> 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.
>
> Is that only for custom serialization or a general requirement?

See my previous answer.

http://forum.dlang.org/thread/sctofkitoaxftosxtspw@forum.dlang.org#post-sctofkitoaxftosxtspw:40forum.dlang.org

On Monday, 18 November 2013 at 15:32:30 UTC, Atila Neves wrote:
>> 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.
>
> I promise to announce and explain it soon. Maybe even today. I just have to fix one small detail.