Serialization for D. Comments, please!

[grauzone]

>> tupleof _can_ access private members, even if the type is from a
>> different module than the function that uses the tupleof. This changed
>> somewhere between dmd 1.030 and 1.040, I think.
> 
> If it can, I would consider that a bug.

It would be nice to get an official statement.

> 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. But using mixins and adding unknown members from the 
serialization machinery isn't that clean either. At leasr 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).

By the way, how are you going to solve the other problems when 
serializing D types? Here are some troublesome types:
- pointers?
- function pointers?
- delegates?
- unions?
- deserializing members that are const/immutable?
- referential integrity across arrays and slices?

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

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