Fixing C's Biggest Mistake

[Sergey]

On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright 
wrote:
> On 12/21/2022 11:38 AM, Don Allen wrote:
> 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

At last Beerconf I’ve made a poll for Jitsy users about tools for 
C interaction. ImportC got 0 votes…
the winner btw “manual export(C)” with 3 votes.
Of course the statistic is not representative, but still.

> 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

I really hardly imagine a solid C developer (like the level of 
OpenBSD hacker or Linux/Git kernel) who will use ImportC to have 
this feature, instead  of using gcc/clang/specific compiler for 
target(intel,nvidia,etc)

> 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.

There is no code with this syntax. D needs that ImportC will 
flawlessly work with current libraries and code, not with “code 
from future with improved features of C45”

> 3. Help get [..] into the C Standard which will help D, too, by 
> making D easier to interface with C

How it helps to get it into C Standard? Isn’t it better to 
prepare PR for GCC and send DIP(or how they call it) to C Core 
community? And after it will be approved and widely used - add it 
to ImportC..

> 4. Getting it into C means better C debugger support for D

Same as above. Maybe use principles of KISS and Unix-way? For 
debugging use specific debugger-tools? Not “other language 
Interoperability tool”?