On Thursday, 7 March 2013 at 12:42:23 UTC, Steven Schveighoffer
wrote:
If the function is optimized, it can essentially bypass the
range layer and operate directly on the buffer while using the
same interface it would use if it were operating on the range.
As I understand it, some of the operations in Phobos do that
as well when given arrays.
This is the wrong track to take.
There have been quite a few people in the D community that have
advocated for the syntax:
int[] arr;
auto p = 5 in arr;
Just like AAs. It looks great! Why shouldn't we have a way to
search for data with such a concise interface? The problem is
then that diminishes the value of 'in'. For AAs, this lookup
is O(1) amortized, For an array, it's O(n). This means any
time a coder sees x in y, he has to consider whether that is a
"slow lookup" or a "quick lookup". Not only that, but generic
code that uses the in operation has to insert caveats "this
function is O(n) if T is an array, otherwise it's O(1)". The
situation is not something we want.
Maybe "takeArray" is a bad design, but it was just an example.
The "block input"/"slice-assignable" range idea would still work
well, though.
We could provide a "RangeStream" type which shoehorns any range
into a stream, but I'd want it tucked in some shadowy corner of
Phobos, not to be used except in emergencies when nothing else
will do. It should be discouraged.
One of my main reasons for wanting ranges as the input was to
allow this sort of an interface. This looks like a usable
solution for that need.
I hope my above comments have made clear that I am not against
having ranges be forcibly changed into streams. What I don't
want is ranges implicitly treated as streams.
I'd say that my idea is more about having ranges implicitly
treated as stream sources rather than as true streams, but having
a method to explicitly make them stream sources would still be
quite usable.
Ultimately, I think that the differences between our designs boil
down to having a more monolithic stream interface with an
internal stream source or having a lighter-weight but more ad-hoc
stream interface with an external and more exposed stream source.
At this point, I'd probably be happy with either as long as they
have equivalent functionality.
