Serialization for D. Comments, please!

[BCS]

Hello grauzone,


>> And even if Walter sanctions it, I wont use it because I'm very leery
>> of generating a system that automaticly reaches in from the outside
>> and mucks with private members. Whoever makes a type serializeable
>> needs to put at least some thought into how to serialize it. If it is
>> the type's
>> 
> That's why I'd still require types to be marked as serializeable by
> the programmer.

How would you do that aside from mixins?

> But using mixins and adding unknown members from the
> serialization machinery isn't that clean either.

I'm not going to fix it now, but I have a few ideas how I can only add the 
public API to the types. That would be one non static serialization function 
and a static deserialization function.

> At least for all
> those structs, it's truly annoying and unneeded. Having to use
> different mixins for structs/classes sucks even more (wouldn't be
> required if you wanted).

It isn't required, the difference is not struct vs. class but "do you care 
about repeated references to instances of this type?"

> 
> By the way, how are you going to solve the other problems when
> serializing D types? Here are some troublesome types:
> - pointers?

class references are pointers, for struct and what not, I'll just use a similar 
approach

> - function pointers?
> - delegates?

I won't

> - unions?

for those I'll provide a way for the user to define the serialization themselves.

> - deserializing members that are const/immutable?

D1, when I get to that; the same way you generated them anywhere else? I 
might even go with "unsafe" casts as I can be sure to get that correct.

> - referential integrity across arrays and slices?

I won't

> Also, it seems I just spotted a bug: floating point numbers loose
> precision as they are formatted with "%s".

I suppose that should be "%A" I'll get to that at some point.

> 
>> author, I'm comfortable with them saying "just do everything", but if
>> someone else is doing it, that is likely to get feet shot off. If I
>> made a generic "any type" function, it would recur into any
>> referenced types and either spew a big list of type that it's dealing
>> with (that people won't look at) or give no warning that it's walking
>> into new territory and that it may not be doing valid operations.
>> 
> I didn't understand the last sentence.
> 

First off there is not enough information to correctly generate sterilizers 
for types. So the user has to do some thinking for most types. How do I make 
the user thinks about how and for what types code is being generated?

Option 1) have the template run a paramg(msg,T.stringof) for each type and 
hope the user don't just ignore the list.
Option 2) do nothing and be sure the user won't see anything.
Option 3) Make the user write per type code and error when they don't.