https://news.ycombinator.com/edit?id=34084894

I'm wondering. Should I just go ahead and implement [..] in ImportC?

On 12/21/2022 11:09 AM, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
> 
> I'm wondering. Should I just go ahead and implement [..] in #ImportC?

Vote here:

https://twitter.com/WalterBright/status/1605642794965483521

On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

Could you please post what's going on for those who can't access the link?

Matheus.

On 12/21/2022 11:22 AM, matheus wrote:
> On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
>> https://news.ycombinator.com/edit?id=34084894
>>
>> I'm wondering. Should I just go ahead and implement [..] in ImportC?
> 
> Could you please post what's going on for those who can't access the link?

I posted this on Hacker News in response to an article about Microsoft's Checked C.
=======================
Checked C:

    int a[5] = { 0, 1, 2, 3, 4};
    _Array_ptr<int> p : count(5) = a;  // p points to 5 elements.

My proposal for C:

    int a[5] = { 0, 1, 2, 3, 4};
    int p[..] = a;  // p points to 5 elements.

https://www.digitalmars.com/articles/C-biggest-mistake.html

https://github.com/Microsoft/checkedc/wiki/New-pointer-and-a...

On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

I thought the intent of ImportC was primarily to facilitate the use of C libraries, e.g., sqlite, from D without having to manually translate function prototypes and other definitions (such as typedefs).

What you seem to be proposing is an extension to the C language that the ImportC compiler (which is a C compiler) understands. How is fixing a problem in C that the C community hasn't agreed is a problem in a way it hasn't agreed to of benefit to the D community?

Wouldn't it be better to devote ImportC time and effort to extending ImportC's understanding of existing variants of C used in libraries that it currently doesn't understand (I've documented examples of this in a recent bug report that you asked me to file)?

Perhaps I'm missing something here. If so, please enlighten me.

/Don

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

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

On 12/21/2022 12:25 PM, Don Allen wrote:
> 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 have some experience implementing things that no sane person wants, and it becoming a game changer. Of course, I can't know this in advance. But I'm not afraid to try.


> 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.
I agree with you on the importance of improving ImportC's abilities to handle common .h files with their wacky use of C extensions. I just did another improvement for that a couple days ago.

On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright wrote:
> But to address your point, ImportC has been a big success for D.

How did you determine this? Most people I've talked to either haven't actually used it or have had (predictable) trouble with it. A small minority of D users actually find value in it right now.

As I've been saying for a while, I agree it has some potential, but it has not been a big success yet.