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.
