std.serialization: pre-voting review / discussion

ilya-stromberg ilya-stromberg-2009 at yandex.ru
Wed Aug 28 09:02:03 PDT 2013


On Friday, 23 August 2013 at 13:39:47 UTC, Dicebot wrote:
> On Friday, 23 August 2013 at 13:34:04 UTC, ilya-stromberg wrote:
>> It's a serious issue. May be it's more important than range 
>> support. For example, I have to change class (bug fixing, new 
>> features, etc.), but it comparable with previos version 
>> (example: it's always possible to convert "int" to "long"). I 
>> that case I can't use std.serialization and have to write own 
>> solution (for examle, save data in csv file).
>
> I don't think it as an issue at all. Behavior you want can't be 
> defined in a generic way, at least not without lot of UDA help 
> or similar declarative approach. In other words, the fact that 
> those two classes are interchangeable in the context of the 
> serialization exists only in the mind of programmer, not in D 
> type system.
>
> More than that, such behavior goes seriously out of the line of 
> D being strongly typed language. I think functionality you want 
> does belong to a more specialized module, not generic 
> std.serialization - maybe even format-specific.

Maybe you are right.
But I think it's not so difficult to implement, at least for 
simle cases.
We can follow a simple rules, for example like this:

Does element "b" exists in the archive? - Yes.
Does element "b" has type "long"? - No, the type is "int".
Can we convert type "int" to "long"? - Yes, load element "b" to 
tempory variable and convert it to "long":

int _b = 4;
long b = to!long(_b);

Is it difficult to implement?
Also, we can provide a few deserialize models: strict (like 
current behavior) and smart (like example above). May be even 3 
levels: strict, implicit conversions (like int to long) and 
explicit conversions (like long to int).


More information about the Digitalmars-d mailing list