deprecating std.stream, std.cstream, std.socketstream

[Steven Schveighoffer]

On Mon, 14 May 2012 22:56:08 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 5/14/2012 8:02 AM, Steven Schveighoffer wrote:
>> I keep trying to avoid talking about this, because I'm writing a  
>> replacement
>> library for std.stream, and I don't want to step on any toes while it's  
>> still
>> not accepted.
>>
>> But I have to say, ranges are *not* a good interface for generic data  
>> providers.
>> They are *very* good for structured data providers.
>>
>> In other words, a stream of bytes, not a good range (who wants to get  
>> one byte
>> at a time?). A stream of UTF text broken into lines, a very good range.
>>
>> I have no problem with getting rid of std.stream. I've never actually  
>> used it.
>> Still, we absolutely need a non-range based low-level streaming  
>> interface to
>> data. If nothing else, we need something we can build ranges upon, and  
>> I think
>> my replacement does a very good job of that.
>
> I'll say in advance without seeing your design that it'll be a tough  
> sell if it is not range based.
>
> I've been doing some range based work on the side. I'm convinced there  
> is enormous potential there, despite numerous shortcomings with them I  
> ran across in Phobos. Those shortcomings can be fixed, they are not  
> fatal.
>
> The ability to do things like:
>
>   void main() {
>    stdin.byChunk(1024).
>       map!(a => a.idup). // one of those shortcomings
>       joiner().
>       stripComments().
>       copy(stdout.lockingTextWriter());
>   }

I think we may have a misunderstanding.  My design is not range-based, but  
supports ranges, and actually makes them very easy to implement.

byChunk is a perfect example of good range -- it defines a specific  
criteria for determining an "element" of data, appropriate for specific  
situations.

But it must be built on top of something that allows reading arbitrary  
amounts of data.  At the lowest level, this is the OS file  
descriptor/HANDLE.

To be efficient, it should be based on a buffering stream.  That buffering  
stream *does not* need to be a range, and I don't think shoehorning such a  
construct into a range interface makes any sense.

To make this clear, I can say that any range File supports, my design will  
support *as a range*.

To make it even clearer, the current std.stdio.File structure, which you  
have shown to "kick ass" with ranges, is *NOT* range-based by my  
definition.

I should note, the output range idiom is directly supported, because the  
output range definition exactly maps to an output stream definition.

-Steve