why is string not implicit convertable to const(char*) ?

[Jonathan M Davis]

On Thursday, July 05, 2012 18:57:05 Wouter Verhelst wrote:
> Jonathan M Davis <jmdavisProg at gmx.com> writes:
> > On Thursday, July 05, 2012 21:32:11 dcoder wrote:
> >> Thanks for the thorough explanation, but it begs the question why
> >> not make strings be array of chars that have \0 at the end of it?
> >> 
> >>   Since, lots of D programmers were/are probably C/C++
> >> 
> >> programmers, why should D be different here?  Wouldn't it
> >> facilitate more C/C++ programmers to come to D?
> >> 
> >> Just curious.
> > 
> > Are you serious? I'm shocked to hear anyone suggest that. Zero-terminated
> > strings are one of the largest mistakes in programming history. They're
> > insanely inefficient. In fact, IIRC Walter Bright has stated that he
> > thinks that having arrays without a length property was C's greatest
> > mistake (and if they'd had that, they wouldn't have created
> > zero-terminated strings).
> > 
> > C++ tried to fix it with std::string, but C compatability bites you
> > everywhere with that, so it only halfway works. C++ programmers in
> > general would probably have thought that the designers of D were idiots
> > if they had gone with zero- terminated strings.
> > 
> > You don't do what another language did just to match. You do it because
> > what they did works and you have no reason to change it. Zero-terminated
> > strings were a horrible idea, and we're not about to copy it.
> 
> To be fair, there are a _few_ areas in which zero-terminated strings may
> possibly outperform zero-terminated strings (appending data in the case
> where you know the memory block is large enough, for instance). But
> they're far and few between, and it would indeed be silly to switch to
> zero-terminated strings.

Actually, I'd expect a string that maintains its length to beat a zero-
terminated string at that - especially because you'd have to already know the 
string's length to pull that off, which is O(n) for zero-terminated strings. 
The _only_ time that the zero-terminated string might outperform the one which 
maintained its length when you to append is if you already happen to know the 
length of the string being appended to and the string being appended (which 
you wouldn't normally with zero-terminated strings), because then the zero-
terminated string would have one more byte to copy as part of its memcpy than 
the other string would, but the other string would have to adjust its length, 
making it cost _slightly_ more. But really, given the overal costs of zero-
terminated length, it would be ridiculous to even count that extra bit of 
performance given the _huge_ performance losses everywhere else with them.

The _only_ valid excuse that I'm aware of for picking such a horrid design is 
the fact that it costs extra memory to maintain the length of an array along 
with the array, and when C was created, they cared a _lot_ more about memory 
usage than we do today. So, regardless of what the pros or cons were in the 
short run, in the long run, their decision was a very poor one that pretty 
much no one has duplicated.

I really see no reason to cut them any slack for such a horrible design 
decision.

- Jonathan M Davis