Poll: Primary D version

[Mike Parker]

Rainer Deyke wrote:
> On 5/22/2010 23:16, Mike Parker wrote:
>> That's not the problem. The problem is this:
>>
>> const(char)* toStringz(const(char)[] s);
>>
>> There's no equivalent for:
>>
>> char *toStringz(char[] s);
>>
>> Hence the need to cast away const or use a wrapper for non-const char*
>> args.
> 
> There is no way to define this function with the correct semantics in D.
>  'toStringz' must append a null character to the string, therefore it
> cannot return a pointer to the original string data in the general case.
>  If you pass the resulting string to a function that mutates it, then
> the changes will not be reflected in the original string.
> 
> If you pass the resulting string to a function that does /not/ mutate
> it, then that function should be defined to take a 'const char *'.
> 
> 

I understand that. But, ignoring the fact that toStringz in D1 seems to 
have functioned perfectly fine for several years without a const return, 
it doesn't change the fact that a C function call that accepts a char* 
expects it to be null-terminated, regardless of what happens to it on 
the other side.

And I would argue that it's unreasonable to expect the declarations of C 
functions to be declared const-correct based on their usage. To my 
knowledge, all of the C bindings for D to date either don't use const at 
all (because they were created for D1) or use it according to the 
declarations in the C headers. Which means there are numerous C 
functions out there with non-const params that do not modify them.

Then there's the issue of compatibility between D1/D2. I've bound 
several C libraries for D that need to support both D1/D2, Phobos/Tango. 
Supporting const was one of the first headaches I encountered when 
porting the original D1 bindings to D2. Finding that toStringz returned 
a const string was a big surprise.