I want to say first that I'm really impressed with D.  I found it at Slashdot about 6 months ago or so and I remembered it all this time.  Just found it again as I'm pretty tired of C++ and refuse to learn Java.  So I hope to have a few *constructive* things to say here.  I hope I'm not nitpicking.

As I read the docs I can find on D, I was imagining introducing it at work as a great arbitrator between the complexity of C++ and the ideology of Java.  I think it is time for prudent garbage collection (selectably) and I think it is time for any work-horse language to have a fully-functional, first-class string.  But I don't like the "everything is an object" mentality and I think it shows a lack of "engineering prowess" on the part of its rabid Java fans.  (am I pissing anyone off? :-))

The idea of connecting to any C library was also awesome and very important. What a clever way to avoid full backwards compatability (like C++) while also allowing the use of 15 year old code bases!

So for my first "complaint"...

I understand using old C libraries, especially ones for esoteric things and in-house libraries, but I'm not so sure about std.c.stdio and std.c.stdlib. This is the first D code that shocked me:

    return strcmp(std.string.toCharz(s), "foo\0");
    printf("my string is: %.*s\n", string);

So, if I understand, it will be common practice to use printf and then require either "%.*s" or "foo"~"\0".  Ouch!  This will be a huge source of forgetful bugs.  And yet I love printf as much as the next person.  (The above is also approaching the hard to read category of coding.)  This is the first time I felt like NOT showing D to colleagues, I hate to say.

A possible solution might be a std.printf.  It would recreate these important c functions in a way that is D safe.  (Again, C backwards compatibility is awesome, but we wouldn't have to be ideological in it's application.)  Yeah, I don't love this implementation either but it might be worth a debate.  I like the idea of having printf, of course, but "std.print" might get confused with "std.c.printf" while the newbie stares at it for an hour wondering what went wrong.

Would it possible to force a c.printf() for functions in std.c.stdio?  Then printf() would be the new D version.

Charlie Patterson wrote:

> A possible solution might be a std.printf.  It would recreate these important c functions in a way that is D safe.  (Again, C backwards compatibility is awesome, but we wouldn't have to be ideological in it's application.)  Yeah, I don't love this implementation either but it might be worth a debate.  I like the idea of having printf, of course, but "std.print" might get confused with "std.c.printf" while the newbie stares at it for an hour wondering what went wrong.
>
> Would it possible to force a c.printf() for functions in std.c.stdio?  Then printf() would be the new D version.

You need to look up the new writef function.
It is the D version of printf, and then some.

It's located in std.stdio.
"sprintf" is in std.format.

--anders

>> Would it possible to force a c.printf() for functions in std.c.stdio? Then printf() would be the new D version.

Oops.  Everytime I wrote std.c.printf I meant std.c.stdio and when I wrote std.printf I meant std.stdio as a replacement.

> You need to look up the new writef function.
> It is the D version of printf, and then some.

Sounds good.  But my concern is that there are lots of C functions that use C strings and also have a lot of mental stickiness.  You renamed printf to writef for this case, but what about strcpy, fopen, connect, etc?  I could see converting people much more easily if somehow these names stayed and also behaved well with D strings.  (And there would be a lot less bugs.) Maybe the C libraries could somehow require c. prepended if there is also a D version of the string?

Charlie Patterson wrote:

>>You need to look up the new writef function.
>>It is the D version of printf, and then some.
> 
> Sounds good.  But my concern is that there are lots of C functions that use C strings and also have a lot of mental stickiness.  You renamed printf to writef for this case, but what about strcpy, fopen, connect, etc?  I could see converting people much more easily if somehow these names stayed and also behaved well with D strings.  (And there would be a lot less bugs.) 

D uses a lot of standard C functions... Usually in modules
prefixed by an extra .c, such as std.c.stdio and std.c.stdlib

i.e. std.stdio does a "import std.c.stdio;"
     std.zlib does "import etc.c.zlib";
     and so on and so forth

So the C standard library is required, and using external
libraries usually just means doing a import module for D
and linking to the standard C libraries, not rewriting it...

> Maybe the C libraries could somehow require c. prepended if there is also a D version of the string?

The full module names can be used to separate, if conflicts ?

All D strings can be casted to (char*), but you usually want
to add a terminating NUL to it (and possibly convert encoding)

--anders

> So for my first "complaint"...
>
> I understand using old C libraries, especially ones for esoteric things and
> in-house libraries, but I'm not so sure about std.c.stdio and std.c.stdlib.
> This is the first D code that shocked me:
>
>     return strcmp(std.string.toCharz(s), "foo\0");
>     printf("my string is: %.*s\n", string);
>
> So, if I understand, it will be common practice to use printf and then
> require either "%.*s" or "foo"~"\0".  Ouch!  This will be a huge source of
> forgetful bugs.  And yet I love printf as much as the next person.  (The
> above is also approaching the hard to read category of coding.)  This is the
> first time I felt like NOT showing D to colleagues, I hate to say.
>
> A possible solution might be a std.printf.  It would recreate these
> important c functions in a way that is D safe.  (Again, C backwards
> compatibility is awesome, but we wouldn't have to be ideological in it's
> application.)  Yeah, I don't love this implementation either but it might be
> worth a debate.  I like the idea of having printf, of course, but
> "std.print" might get confused with "std.c.printf" while the newbie stares
> at it for an hour wondering what went wrong.
>
> Would it possible to force a c.printf() for functions in std.c.stdio?  Then
> printf() would be the new D version.

The docs have a lot of really outdated stuff. toCharz() has been deprecated for ages. D now has a printf replacement called writef (and writefln) from std.stdio:
   writefln("my string is: %s", string);
and it's type safe.
You might also want to check out this page http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers and other stuff from the wiki.