On 9/3/2011 3:53 PM, dsimcha wrote:
Agreed, but in the big picture this overhaul still breaks way too much code
without either a clear migration path or a clear argument about why such
extensive
breakage is necessary. The part about File(someFileName, someMode) is just the
first thing I noticed.
[rant]
I agree. I agree that std.stream should be replaced, but I have a lot of
misgivings about replacing std.stdio. I do not want to rewrite every darn D
program I've ever written. I think it is a bad idea to break everyone else's D
program.
Everything in dsource will break in non-trivial ways. I don't think we can
afford this. I do not know of any successful system or language that breaks user
code with such aplomb as D does. Not even C++ dares to break that Piece Of S***
that everyone knows iostreams is. I can compile and run unix C code from 30
years ago on Linux with no changes at all. Same with DOS code.
There needs to be huge improvement to justify such breakage.
[I also don't like it that all my code that uses std.path is now broken.]
I would prefer to see all the energy that is going into refactoring existing,
working modules go into designing new, not existing, modules that there's a
crying need for.
[/rant]
Enough ranting for now, as for the proposed std.stdio,
1. It does look fairly straightforward, but:
2. There is only one example. Have any commonly done programming tasks been
tried out with it to see how they work?
3. There is no indication of how it interacts with C stdio. A primary goal of
std.stdio was interoperability with C stdio.
4. There are no benchmarks. The current std.stdio was designed/written in
parallel with some benchmarks Andrei and others cooked up, as a primary goal was
performance.
5. flushCheck - flushing should be done based on the file type. tty's should be
\n flushed, files when the buffer is full. I question the performance of using a
delegate to check for flushing. How often will it be called?
6. There is no provision for multithreaded writing, i.e. what happens when two
threads write to stdout. Ideally, there should be a way to 'lock' the stream to
oneself, in order to appropriately interleave the output.
7. I see nothing for 'raw' character by character input.
8. I see nothing for determining if a char is available on the input. How would
one implement "press any key to continue"?
