Fixing C's Biggest Mistake

[Don Allen]

On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright 
wrote:
> On 12/21/2022 11:38 AM, Don Allen wrote:
>> Perhaps I'm missing something here. If so, please enlighten me.
>
> ImportC already has a couple extensions from D to make 
> programming in it easier.
>
> But to address your point, ImportC has been a big success for 
> D. People trying to interface D with C and C++ have many times 
> lamented the lack of dynamic arrays in C and C++, leading to 
> ugly interface hacks.
>
> The advantages are:
>
> 1. drawing attention to ImportC, which will draw attention to D
>
> 2. D can call ImportC code, and ImportC code can call D code. 
> This will make one of the most-used features of D easy to cross 
> over between the two languages.
>
> 3. Help get [..] into the C Standard which will help D, too, by 
> making D easier to interface with C
>
> 4. Getting it into C means better C debugger support for D

I read your paper/discussion of C's biggest mistake. I'm not 
prepared to agree that what you discuss is The Biggest, but it's 
certainly up there in the long list of C's mistakes. So I think 
your argument is persuasive. But it is far from clear to me that 
making that argument by implementing your proposed new construct 
in ImportC is the best way to go about this.

For example, you say

2. D can call ImportC code, and ImportC code can call D code.
This will make one of the most-used features of D easy to cross
over between the two languages.

Again, I thought the intent of ImportC was to facilitate access 
to useful existing  C libraries. If the C community doesn't have 
an instant epiphany and adopt your position of making a 
distinction between arrays and pointers because you added that 
feature to ImportC, then your effort is going to be greeted with 
the sound of one hand clapping.

I think it would be much better if you argued for your proposed 
change to C to the C-powers-that-be and devoted your ImportC 
efforts to extending its coverage of existing C dialects. I think 
*that* would be the best way to make ImportC a big win for D. 
Zig's C translator handles the include files (gtk.h and 
everything it drags in and sqlite3.h as well) that ImportC does 
not. I think your goal for ImportC should be to make it as 
comprehensive as the Zig translator. And your key advantage is 
that D is here now, production-worthy, whereas Zig won't be ready 
until 2025, according to Kelley's latest roadmap (and based on 
what I've seen from watching that project, he might well be 
optimistic).