On Sunday, 18 August 2013 at 14:24:38 UTC, Tobias Pankrath wrote:
On Sunday, 18 August 2013 at 08:38:53 UTC, ilya-stromberg wrote:
As I can see, we have a few options:
- accept std.serialization as is. If users can't use
std.serialization due memory limitation, they should find
another way.
- hold std.serialization until we will have new std.xml module
with support of range/file input/output. Users should use
Orange if they need std.serialization right now.
- hold std.serialization until we will have binary archive for
serialization with support of range/file input/output. Users
should use Orange if they need std.serialization right now.
- use another xml library, for example from Tango.
Ideas?
We should add a suitable range interface, even if it makes no
sense with current std.xml and include std.serialization now.
For many use cases it will be sufficient and the improvements
can come when std.xml2 comes. Holding back std.serialization
will only mean that we won't see any new backend from users and
would be quite unfair to Jacob and may keep off other
contributors.
I completely agree.
I'm the one that brought it up, and I mostly brought it up so the
API doesn't have to change once std.xml is fixed. I don't think
changing the return type to a range will be too difficult or
memory expensive.
Also, since slices *are* ranges, shouldn't this just work?
