On Fri, Sep 07, 2007 at 07:03:24PM +0000, Walter Bright wrote:
> 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.

  Well htod does that, but it's very impractical to write them from
scratch. Especially if you want to benefit from the fact that padding
and integer sizes are very well defined to map e.g. structs onto a raw
stream, avoiding deserialization and so on. And for that bit-fields are
a really really fast and simple way to describe things.

  I mean, take your classical example of the foreach loop. Your whole
point is that it's way shorter, and safer. And now you are saying that
people should instead of sth like:

  struct my_struct {
    unsigned some_field : 2;
    unsigned has_this_property : 1;
    unsigned is_in_this_state  : 1;
    unsigned priority_level    : 2;
    ...
  }

  people should write (IIRC it works since ->some_field = 2 calls
->some_field(2) if the member does not exists, or maybe it's
set_some_field, it's not very relevant anyway):

  struct my_struct {
    unsigned some_field() {
      return this->real_field >> 30;
    }

    void some_field(unsigned value) {
      this->real_field |= (value & 3) << 30;
    }

    ...

  private:
    unsigned real_field;
  }

  Please it has to be a joke: there is 42 ways for people to write it
wrong (wrong shifts, wrong masks, and so on), it's horribly obfuscated,
hence needs a lot of comments, whereas the bitfield is 90% self
documented, and the syntax is _very_ clear, you cannot beat that. I
would be absolutely fine with it being syntactical sugar for some kind
of template call though.

  Not to mention that the usual C idiom:

  union {
    unsigned flags;
    struct {
      // many bitfields
    };
  };

  Would need an explicit copy_flags(const my_struct foo) function to
work. Not pretty, not straightforward.

  Really, I feel this is a big lack, for a language that aims at
simplicity, conciseness _and_ correctness.

  OK, maybe I'm biased, I work with networks protocols all day long, so
I often need bitfields, but still, a lot of people deal with network
protocols, it's not a niche.

> >  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.

  Last time I checked it was only available on windows, and closed
source, both are an impediment for many people. It's definitely clear
that gcc being opensource and available on so many platforms helped to
make C what it is today. Lacking portable and free (as in speech) tools
are an impediment to the succes of a language. Right now, for D, only
gdc exists, it lags behind dmd quite a lot afaict, and there is no other
toolchain helpers yet.

> 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.

  Yeah I'm fine with that, but sadly it's not available everywhere like
I said.

> >  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.

  I completely agree, and I knew about Tango, and anyways, I'm so used
to C, and D has so few to bring to my code style when I deal with low
level system functions, that I'm totally fine with std.c.* anyways :)

  For the record I wasn't suggesting to rewrite git in D at all. I just
happened to see your post, and being very interested in where D is going
because I feel it's an excellent langage, and saw an opportunity to
mention a few quirks I feel it has, so, well, I answered :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org