Tango / Phobos / future dilemma

[Yigal Chripun]

Koroskin Denis wrote:
> On Tue, 27 May 2008 18:49:26 +0400, Frits van Bommel
> <fvbommel at remwovexcapss.nl> wrote:
> 
>> Sascha Katzner wrote:
>>> I see no reason why those two IO systems couldn't coexist on top of a
>>> common low level cache.
>>
>> (All of the statements below are AFAIK & IIRC from the newsgroup
>> discussions on this subject)
>>
>> I do:
>> Walter seems convinced that using the libc buffering is the Right
>> Thing To Do(TM) because it allows intermixing of *printf(), putc*(),
>> etc. with writefln & friends without explicitly syncing them.
>> The Tango devs have a good reason to use their own, separate,
>> buffering solution: the tests showing better performance. (And many
>> people consider it bad style to use C-style I/O in D programs anyway,
>> so "it's just not worth it" becomes a good argument pretty quickly here)
>>
>> This just doesn't allow a "common low level cache" since neither of
>> their buffering solutions allows the use of a common buffer unless the
>> other one switches (Phobos can't change libc while much of the Tango
>> IO functionality depends on using the custom buffer and its good
>> performance depends on interfacing directly to the OS[1])...
>>
>> In other words, it's a fundamental disagreement about how to best do I/O.
>>
>>
>>
>> [1] Also, changing the Tango I/O code to use libc instead of direct OS
>> calls isn't very helpful since it still won't be synced to C-style I/O
>> (there'll still be an extra buffer in front of the Tango stuff that
>> would only send stuff to libc when full or explicitly flushed).
> 
> C++ has both C-style stdio (fopen, fwrite, etc) and custom iostreams.
> Both of them have overlapping functionality, and no one cares.
> 
> Since D can directly interface with C code and we can't throw away that,
> C-style IO _will_ present in D. And that's Ok, I don't see any problems
> here. Guys that think that it's the right way would use that, others would
> use Tango way.

C++ has duplicated functionality for many of the C constructs like IO,
casting,  arrays vs. stl vectors, etc..
I wouldn't say that no one cares, on the contrary, this is a source for
 confusion and bugs, it adds unneeded complexity which IIRC is one of
the reasons for creating D in the first place.
C++ already provides this awful solution with its backwards
compatibility, so if you want to mix code just use C++ (I have to do
this at work and it's a huge PITA).
D provides only linking capability to C libraries and I'd prefer the
faster Tango implementation which needs explicit syncing of IO instead
of crippling the entire D language. I imagine that the needed explicit
syncing can be provided as part of Tango.
Besides, how many use-cases are there for linking c libraries to your D
code which use C IO? I assume of course that C libraries will be linked
to D code only when there's no suitable D code that accomplishes the
same thing.
for example, if I need a regexp lib I can simply use Tango's regexp
package which is both more convenient to use and faster than equivalent
C/C++ libs. Had I used a C lib I would have needed to take care of the
differences between C and D in my code _anyway_ because of other issues
like memory handling for example.

according to your logic, would you suggest D needs to get rid of its GC
to be compatible to the C memory handling mechanisms?
I personally like the GC, and I prefer that the programmer will need to
explicitly change the default memory handling for those rare IMO cases
when this is needed instead of making use of malloc as the default in D.

People keep forgetting here that D is a _new_language_ and should be
developed accordingly and not as an extension to C++ and it's idioms. We
already have C++ (and the future c++0x standard) for that.

--Yigal