Poll: Primary D version

[Andrei Alexandrescu]

On 05/23/2010 04:47 AM, Pelle wrote:
> On 05/23/2010 10:14 AM, Mike Parker wrote:
>> 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.
>>
>
> I do them according to the C headers, and the constness is almost always
> correct. Otherwise, it's a bug in the C headers!

Yes. My experience with C headers is that they're always careful about 
inserting const for read-only pointer parameters.

>> 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.
>
> It should probably be inout(char)* toStringz(inout(char)[]), or
> something like that.

It could, but what C functions output to a zero-terminated char*? I can 
only think of unsafe ones, such as strcat() and gets(). Both are 
inherently unsafe.


Andrei