Phobos file input (Was: Re: List of issues PVS-Studio statically analyzes for )

[Timon Gehr]

Walter Bright wrote:
> On 7/23/2011 4:10 AM, bearophile wrote:
>> D doesn't currently catch errors coming from [...]
>> bad usage of core.stdc functions (like strlen, printf, etc).
>
>
> This isn't likely to happen. D's mission isn't to try and fix usage of C functions.

Note that currently, unsafe cstdio functions are often faster than Phobos stdio
functions by a factor large enough to force people to use the C functions for IO
bound tasks.
I don't know how many people on this newsgroup are affected by this fact. What is
important to note is: This issue is a blocker for using D as a teaching language
at universities.

std.stdio is completely compatible with cstdio functions, but that is both a
benefit and a drawback:
- cstdio can be used at no extra cost, very nice if you need it.

- Phobos input functionality (mainly readf) is slowed down, since it cannot use an
internal buffer.
-- This even applies when cstdio is not used at all!
-- a large part of the inefficiency of readf may be caused by the range
abstraction for files: std.stdio.LockingTextReader.empty looks like a bottleneck.
-- C++ iostreams 'solves' it with ios::sync_with_cstdio(false);

- Another more fundamental issue is that D IO cannot be atomic. There is no way to
implement a function that leaves the input untouched if it is invalid, and still
is compatible to cstdio.

Eg:
try a = read!int(); // oops, input is actually "abc"
catch(...){s = read!string();} // get malformed input

Currently in case of ill-formed input, formattedRead leaves the InputRange (which
is real file input in the case of readf) in whatever position the error occured,
and I'm not sure if this is even specified anywhere. It is almost useless for
error handling.

So, if D/Phobos basically forces usage of C functions then it's job would actually
be to fix their usage. Otherwise, this is an open design issue.

Any thoughts on how to improve the current situation? I think Phobos should get
_input_ right eventually. (and output too, what is the state of the toString issue?)

- Timon