Early std.crypto

[Dmitry Olshansky]

On 26.10.2011 10:28, Steve Teale wrote:
>>
>> An easy test is that if the interface takes a T[] as input, consider a
>> range instead. Ditto for output. If an interface takes a File as input,
>> it's a red flag that something is wrong.
>
> I have a question about ranges that occurred to me when I was composing a
> MySQL result set into a random access range.
>
> To do that I have to provide the save capability defined by
>
> R r1;
> R r2 = r1.save;
>
> Would it harm the use of ranges as elements of operation sequences if the
> type of the entity that got saved was not the same as the original range
> provider type. Something like:
>
> R r1;
> S r2 = r1.save;
> r1.restore(r2);

Yay! Range with 'restore' strikes again.
Seriously, last time something about range was discussed I noticed this 
very same thing - full copy is costly, there are ranges that can restore 
their state using some special tiny savepoint object.
Though currently this kind of thing is not supported nor expected, plus 
there are cases where copy needs to be made.

>
> For entities with a good deal of state, that implement a range, storing
> the whole state, and more significantly, restoring it, may be non-
> trivial, but saving and restoring the state of the range may be quite a
> lightweight affair.
>
> I'm also puzzled by the semantics of the random access range.
>
> If I restrict myself to indexing into the range, then things are fine.
>
> auto x = r[0];
> x = r[10];
> x = r[0];
>
> But if I slip in a few popFront's, then presumably x = r[0] will give me
> a different result.
>
> This just makes me slightly uneasy.
>
> Steve


-- 
Dmitry Olshansky