std.stream replacement

[BLM768]

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.