On Monday, 4 August 2014 at 07:34:19 UTC, Jacob Carlborg wrote:
On Sunday, 3 August 2014 at 18:44:37 UTC, Dicebot wrote:
Before going this route one needs to have a good vision how it
may interact with imaginary std.serialization to avoid later
deprecation.
I suggest only provide functions for serializing primitive
types. A separate serialization module/package with a JSON
archive type would use this module as its backend.
Do you consider structs primitive types? This is probably #1 use
case for JSON conversion.
At the same time I have recently started to think that
dedicated serialization module that decouples aggregate
iteration from data storage format is in most cases
impractical for performance reasons - different serialization
methods imply very different efficient iteration strategies.
Probably it is better to define serialization compile-time
traits instead and require each `std.data.*` provider to
implement those on its own in the most effective fashion.
I'm not sure I agree with that. In my work on std.serialization
I have not seen this to be a problem. What problems have you
found?
http://forum.dlang.org/post/mzweposldwqdtmqol...@forum.dlang.org
