On Mon, Feb 06, 2012 at 05:18:14PM -0800, Jonathan M Davis wrote: > On Monday, February 06, 2012 17:13:28 H. S. Teoh wrote: > > OK, so this thread was supposed to be about WATs in D. Today I found > > one. > > > > std.stdio.File != std.stream.File > > > > which means you can't assign stdin to InputStream. > > > > Yes I know, you need to import cstream and use cstream.din instead, > > but this is very counterintuitive to a newcomer. It certainly > > elicited a WAT from me today when I first ran into this > > schizophrenic split between std.stdio (which is pretty much used in > > every D code example I've seen, which gives the impression that it's > > the "native" and "default" thing to use) and std.stream (which one > > would expect should naturally extend the functionality of std.stdio, > > but it doesn't). > > I guess that it depends on how you think or what you're used to. I > wouldn't necessarily expect std.stream to be related to std.stdio at > all. Certainly. in C++, stream-based and non-stream-based I/O isn't > related at all (or if it is, it's an implementation detail). So, my > general expectation is that they're completely separate, though I > suppose that they don't _have_ to be designed that way.
The thing is, coming from a Linux background, I've become accustomed to the "everything is a file" concept, which entails "file == stream". So I found it very strange to discover that this is not true in D, at least as far as std.stdio is concerned. > Given that std.stream has its own File type, that would make it pretty > obvious that the File from std.stdio would not work with std.stream. > But I guess that you could see a function taking File in std.stream > without having read enough of std.stream's documentation to realize > that it had its own File type. [...] I certainly did not realize this, since the docs refer to "File" rather than "std.stream.File" or "std.stdio.File" explicitly. But even after I realized there were two different File types, it took me yet another while to figure out how to bridge them with std.cstream. This is one of those things that *really* needs good docs for newbies, because it's a point of confusion to the uninitiated that needs to be explained. On another note, I find this divide between std.stream and std.stdio quite jarring. The C++ model is to use <iostream> by default, and optionally provide <cstdio> to those who prefer it. This, I find, makes sense, because streams are a much more powerful concept that subsumes the concept of a file, and having it as default makes sense. Having <cstdio> as an option is merely a concession for C programmers who migrated to C++ (and I'm one of them who still hold on to cstdio over iostream) -- so it's understandable that the two cannot be freely intermixed. In D, however, I did not expect this stream/stdio divide to exist, though I suppose the name "std.stdio" is a kind of giveaway. In any case, std.stdio is used all over the place in D docs and tutorials, besides write/writeln() being a pet example motivating variadic templates, so it seems to hold the equivalent place to <iostream> in C++. As such, I found it strange that this divide between streams and stdio files still persists in D. I would have thought that D should have integrated the two seamlessly into a single subsystem (or otherwise redesigned it in a more logical fashion), rather than perpetuating the schizophrenic divide inherited from C/C++. T -- Маленькие детки - маленькие бедки.
