Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

[Walter Bright <boost@digitalmars.com>]

Pierre Habouzit wrote:
>   Well, to me D has two significant drawbacks to be "ready to use". The
> first one is that it doesn't has bit-fields. I often deal with bit-fields
> on structures that have a _lot_ of instances in my program, and the
> bit-field is chosen for code readability _and_ structure size efficiency.
> I know you pretend that using masks manually often generates better
> code. But in my case, speed does not matter _that_ much. I mean it does,
> but not that this micro-level as access to the bit-field is not my
> inner-loop.

I'm surprised this is such an important issue. Others have mentioned it, 
but regard it as a minor thing. Interestingly, the htod program (which 
converts C .h files to D import files) will convert bit fields to inline 
functions, giving equivalent functionality.

>   The other second issue I have, is that there is no way to do:
>   import (C) "foo.h"
> 
>   And this is a big no-go (maybe not for git, but as a general issue)
> because it impedes the use of external libraries with a C interface a
> _lot_. E.g. I'd really like to use it to use some GNU libc extensions,
> but I can't because it has too many dependencies (some async getaddrinfo
> interface, that need me to import all the signal events and so on
> extensions in the libc, with bitfields, wich send us back to the first
> point).

D does come with htod, which converts C .h files to D files. It's not 
possible to do a perfect job (because of macros), but it comes pretty 
darned close. The reason htod gets so close is because it is actually a 
real C compiler front end, not a perl or regex string processing hack.

Because it (may) require a little hand tweaking of the results (again, 
because C headers may include awful things like:
	#define BEGIN {
	#define print printf(
), it's a separate program rather than built-in.


>   I also have a third, but non critical issue, I absolutely don't like
> phobos :)

You're not the only one <g>. But I'll add that access to the standard C 
runtime library *is* a part of D, so at some level it can't be worse 
than C. There's also another runtime library available, Tango, which is 
very popular.

> Though I'm obviously free to chose another library. D has
> definitely many many many real advances over C (like the .init, .size,
> ... and so on fields, known types, and whatever portability nightmare
> the C impose us). In fact I like to use D like I code in C, using
> modules and functions, and very few classes, as few as I can. And even
> (under- ?) using D like this, it is a real pleasure to work with. I'm
> really eager to see gdc be more stable.

There are a lot of people hard at work on D to make it more stable and 
increase the breadth and depth of tools available. I am fully aware that 
there may be non-technical issues to using D in a project like git, like 
availability of other D programmers, tradition, etc., but in this thread 
I'm concerned mainly with technical issues.

P.S. I'm also NOT suggesting that git be converted to D. Translating a 
working, debugged, 80,000 line codebase from one language to another is 
usually a fool's errand.

Thanks for taking the time to post your thoughts.

-----------
Walter Bright
http://www.digitalmars.com  C, C++, D programming language compilers
http://www.astoriaseminar.com  Extraordinary C++