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

On Wednesday, 28 August 2013 at 16:02:09 UTC, ilya-stromberg wrote:
> ...

There was a good proposal by Dmitry to separate sequential strict serialization for random-access one as two distinct entities. I like it and I think it that is also can solve your problem.

On Wednesday, 28 August 2013 at 16:10:03 UTC, Dicebot wrote:
> There was a good proposal by Dmitry to separate sequential strict serialization for random-access one as two distinct entities. I like it and I think it that is also can solve your problem.

The problem is not only my. Actually, I didn't use C# serialization due this problem - any minimal code change breaks all previously serialized data. But I used .Net 1, maybe in current version solve this.
Can you print the link, please?

On Wednesday, 28 August 2013 at 16:19:20 UTC, ilya-stromberg wrote:
> Can you print the link, please?

http://forum.dlang.org/post/kvj17t$1ash$1@digitalmars.com

(Rigid vs Flexible part)

On 2013-08-28 18:02, ilya-stromberg wrote:

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

I don't think we should add too much of this kind of functionality. There's a reason for why it supports custom serialization. This is a perfect example.

-- 
/Jacob Carlborg

Jacob, what are your current plans on this (considering recent range API discussion thread)?

On 2013-08-31 14:11, Dicebot wrote:
> Jacob, what are your current plans on this (considering recent range API
> discussion thread)?

My todo list looks like this:

- write an overview documentation
- improve the documentation for std.serialization.serializable to indicate it's not required
- implement a convenience function for serializing
- implement a convenience function for serializing to a file
- remove Serializeable
- check only for "toData" when serializing
- check only for "fromData" when deserializing
- split Serializer in to two parts
- make the parts structs
- possibly provide class wrappers
- split Archive in two parts
- add range interface to Serializer and Archive
- rename all archives to archivers
- replace ddoc comments with regular comments for all package protected symbols

Although I'm guessing I won't be able to finish it in time for voting. How much time is it left anyway?

-- 
/Jacob Carlborg

On Saturday, 31 August 2013 at 17:58:57 UTC, Jacob Carlborg wrote:
> My todo list looks like this:
>
> - write an overview documentation
> - improve the documentation for std.serialization.serializable to indicate it's not required
> - implement a convenience function for serializing
> - implement a convenience function for serializing to a file
> - remove Serializeable
> - check only for "toData" when serializing
> - check only for "fromData" when deserializing
> - split Serializer in to two parts
> - make the parts structs
> - possibly provide class wrappers
> - split Archive in two parts
> - add range interface to Serializer and Archive
> - rename all archives to archivers
> - replace ddoc comments with regular comments for all package protected symbols
>
> Although I'm guessing I won't be able to finish it in time for voting. How much time is it left anyway?

Great. No hurry here, there is no hard deadline for voting - I'll put it on pause until you are ready. Just doing some personal bookkeeping. No pressure, just write me an e-mail when ready for next stage.

On 2013-08-31 20:51, Dicebot wrote:

> Great. No hurry here, there is no hard deadline for voting - I'll put it
> on pause until you are ready. Just doing some personal bookkeeping. No
> pressure, just write me an e-mail when ready for next stage.

What I mean is that we usual have a couple of weeks for reviewing and then about one week for voting. I don't want to put the whole review queue on hold.

-- 
/Jacob Carlborg

On Saturday, 31 August 2013 at 19:37:34 UTC, Jacob Carlborg wrote:
> On 2013-08-31 20:51, Dicebot wrote:
>
>> Great. No hurry here, there is no hard deadline for voting - I'll put it
>> on pause until you are ready. Just doing some personal bookkeeping. No
>> pressure, just write me an e-mail when ready for next stage.
>
> What I mean is that we usual have a couple of weeks for reviewing and then about one week for voting. I don't want to put the whole review queue on hold.

You won't. Reviewing is not a blocking operation, if anyone wants to acts as a review manager for some other contribution, nothing prevents from doing it right now. I have simply marked `std.serialization` as "Incorporating review comments" in wiki and given no new comments this round of review can be considered finished.