I don't get your point.

Without a DNI (i.e. D Native Interface) with which to approach D from the underside, we are forced to have C compatibility within D itself, touching C from the upperside, if you like. Frankly (and I guess this is because I'm a pragmatist, eh Bill?) I don't care which it is, but I do think it's important to maximise robustness wherever possible without cause any significant degradation of performance.

As I've argued, this feature would most certainly increase robustness and would also likely increase performance (quality of compiler optimisations allowing).

You say that toStringz() shows up 38 times in your code, and then say there's no win in it for you. This seems contradictory. Have I misunderstood your post?

As for the "purity" of D, I'll have to leave that to those of a more philosophical bent. I'd offer this thought, though: I have a friend who works on the Solaris kernel team, and he tells me they're not thinking of going C++ or Java or anything else other than C, for the "foreseeable future" (which is a long time, I think). Walter's created a language to supercede C (among others), but has wisely put C compatibility into it. It being the case that C compatibility is built in to D, I cannot see the sense in denying ourselves more robustness and efficiency for free, just because it's less pure?


"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b6c7cp$2bh2$1@digitaldaemon.com...
> Bill Cox wrote:
> > In article <b6aph7$1dbp$1@digitaldaemon.com>, Matthew Wilson says...
> >
> >>Anyway, Bill, everyone, do you like the "char null *" idea?
> >>- Doesn't introduce another keyword.
> >>- Surely not hard to parse.
> >>- Improves robustness.
> >>- Doesn't add operations that would not have to be done anyway.
> >>- Leaves it all to compiler's best discretion, so plenty of chances for
> >>being _faster_ than leaving it up to user, which seems to be a theme of
D,
> >>where achievable.
> >
> >
> > From a user point of view, I like the char null*.  The single most
common
> > "Help!, I've crashed my simple D program" post on this newsgroup seems
to have
> > to do with the terminating null, and how it interacts with character
array
> > slicing.
>
> The problems of newbies are eminently ignorable.  It's the problems of people who are indoctrinated that are worth looking into, they're the ones who are going to be running into it in the years following.
>
> About the issue itself, uh... it's a good match for D (as set out at the
> top of the Phobos page), it's not a good match for what I want D to be.
>   I don't like referring to C functions directly, because of
> incompatible signatures, lack of exceptions, weird overloading, and
> extreme operating system variations in Unices - for example, sometimes
> errno is a symbol, sometimes it's a macro calling a function.  Purifying
> this variability is the first task of cross-platform work, which I do
> quite a lot of, and char* is one small factor of the problem.
>
> So altogether there's no win in it for me.  toStringz shows up 38 times in the interface library dig, 0 times in the client program dedit. That's the way it should be.
>

"Bill Cox" <bill@viasic.com> wrote in message news:3E88BE91.6010403@viasic.com...
> I would want to hold built-in string support to just UTF-8.  D could offer some support for the other formats through conversion routines in a standard library.  Having a single string format would surely be simpler than supporting them all.

The next release will provide a module to do all the conversions.

>The next release will provide a module to do all the conversions.

What it won't provide are manipulation routines for the results.  Conversions aren't enough, one wants a consistent design that treats strings the same no matter their encoding.

Mark