Tomek Sowiński wrote:
Philippe Sigaud wrote:
Yah but the type is a range.
But then, so are Map and Filter.
Personally, I do not consider them algorithms per se, they are too
low-level: they're building blocks and, as ranges, should go in std.range.
LevenshteinDistance or bringToFront, those are algorithms.
My own experience of this is that most of the time, I import std.range
only to get map/filter/reduce. That is, without reaching for a real
algorithm. They are in std.algo for 'historical' reasons, because std.algo
precedes std.range.
OK, range then.
From a different angle, I was thinking that assumptions should give more;
look at this:
auto range = [2, 3, 4];
auto sorted = assumeSorted(r);
range[0] = 666; // BANG! assumeSorted replaced range with Range.init
sorted[0] = 666; // BANG! assertion in Sorted's setter went off
range = sorted.dropAssumption;
sorted[0] = 666; // BANG! now sorted's range reference is nulled.
range[0] = 666; // OK... phew!
Assumption producers like sort() would take the range by ref to comply with
this idiom. Of course if you save() the range before it's eaten by
assumeSorted, you can twiddle away through the saved range. Still, it's
better than nothing. Oh, and the unique-like behavior can be expanded onto
assumeUnique and, I dare say, assumeWhatever.
Like it?
Tomek
Like it, just one issue - destructive copy is unlikely to solve any
problems. The big problems arise with long-distance aliasing, much less
from messing with the source of the assignment directly.
Andrei
