Early std.crypto

[Steve Teale]

On Wed, 26 Oct 2011 13:01:14 -0400, Jonathan M Davis wrote:

> On Wednesday, October 26, 2011 03:17 Steve Teale wrote:
>> On Tue, 25 Oct 2011 23:45:58 -0700, Jonathan M Davis wrote:
>> > On Wednesday, October 26, 2011 06:28:52 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);
>> >> 
>> >> 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.
>> > 
>> > It's likely to cause issues if the type returned by save differs from
>> > the original type. From your description, it sounds like the range is
>> > over something, and it's that something which you don't want to copy.
>> > If that's the case, then the range just doesn't contain that data.
>> > Rather, it's a view into the data, so saving it just save that view.
>> 
>> Well, yes Jonathan, that's just what I'm getting at. I want to save
>> just those things that are pertinent to the range/view, not the whole
>> panoply of the result set representation or whatever other object is
>> providing the data that the range is a view of.
>> 
>> I could do it by saving an instance of the object representing the
>> result set containing only the relevant data, but that would be
>> misleading for the user, because it would not match the object it was
>> cloned from in any respect other than representing a range.
>> 
>> Should not the requirement for the thing provided by save be only that
>> it should provide the same view as that provided by the source range at
>> the time of the save, and the same range 'interface'.
>> 
>> Is there an accepted term for the way ranges are defined, i.e. as an
>> entity that satisfies some template evaluating roughly to a bool?
> 
> Ranges are defined per templates in std.range. isForwardRange,
> isInputRange, isRandomAccessRange, etc. And it looks like isForwardRange
> specifically checks that the return type of save is the same type as the
> range itself. I was thinking that it didn't necessarily require that but
> that you'd have definite issues having save return a different type,
> because it's generally assumed that it's the same type and code will
> reflect that. However, it looks like it's actually required.

But is it just required by std.range, or is it required at some 
theoretical level by algorithms that can work with ranges as inputs and 
outputs?

> What you should probably do is have the result set be an object holding
> the data but not be a range itself and then overload opSlice to give you
> a range over that data (as would be done with a container). Then the
> range isn't in a position where it's trying to own the data, and it's
> clear to the programmer where the data is stored.
> 

But in my mind, just from a quick reading of the language definition, 
slices are closely tied to arrays, which as you have already noted, are 
not the best example of a range.

Are ranges just a library artefact, or are they supported by the 
language. They appear to be recognized by foreach, so if they are 
recognized by D, then we should presumably have operator functions 
opInputRange, opForwardRange, and so on, whatever those terms might mean.

If not, then facilities like std.algorithm should have a warning notice 
like cigarettes that says "this facility may not be usable with POD".

Steve