Serialization for D. Comments, please!

[BCS]

Reply to grauzone,

> BCS wrote:
> 
>> Reply to grauzone,
>> 
>>>>> Is there any real reason for all those mixins?
>>>>> 
>>>> which ones?
>>>> 
>>> All used by the user. That would be Serializable and
>>> SerializableRecuring.
>>> 
>> What else would you use? I guess if I really wanted to I could use
>> the same device as for 3rd party types, but that just pushes the
>> mixin to global scope (the functions have to be defined in the same
>> module as the type or they won't be able to access private members)
>> and introduces unneeded performance issues from using function
>> pointers.
>> 
>> If you can spot a better solution, I'm all for it, but I don't see
>> one and don't think this solution is to bad.
>> 
> 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.

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