std.serialization: pre-voting review / discussion

[Tyler Jameson Little]

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?