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

[Lars T. Kyllingstad]

On Tuesday, 15 May 2012 at 15:22:03 UTC, Lars T. Kyllingstad 
wrote:
> On Tuesday, 15 May 2012 at 02:56:20 UTC, Walter Bright 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'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.
>>
>> [...]
>
> I have to say, I'm with Steve on this one.  While I do believe
> ranges will have a very important role to play in D's future I/O
> paradigm, I also think there needs to be a layer beneath the
> ranges that more directly maps to OS primitives.  And as D is a
> systems programming language, that layer needs to be publicly
> available.  (Note that this is how std.stdio works now, more or
> less.)

Also, I wouldn't mind std.*stream getting deprecated.  
Personally, I've never used those modules -- not even once.  As a 
first step their documentation could be removed from dlang.org, 
so new users aren't tempted to start using them.  No 
functionality is better than poor functionality, IMO.

-Lars