On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:
> ...

Walter I have a question regarding C, I remember that in the past you wrote a paper about a solution for the C Arrays, which would be something like storing its size in the first address and increment it to be used, and time you want the array size it would do something like:
 *(p-1) == size.

Could you please share that paper again?

Thanks in advance,

Matheus.

On Sunday, 28 January 2024 at 11:23:45 UTC, Dibyendu Majumdar wrote:
>
> ..
> But this where you get it wrong. This is not a business. The thing about D is that everyone works on what they want to work on. and its perfectly valid for Walter to work on whatever motivates him.
>
> It took me a while to grasp this about the D eco-system, but its key to getting your expectations right. If you want a business like focused approach that managed top-down, this is not it.

So I am pretty sure I fully understand the concept of opensource and also the concept of people volunteering their time to it. I don't need lessons in that ;-)

I have assumed, perhaps wrongly, that (at the time of that PR) there were other people volunteering their time to the compiler as well, besides Walter. In that were true, then a team based approach would not be consistent with slipping this PR in, more or less without warning.

In any case, as I said, my comment is not about the PR itself, but the manner in which it was pulled. Even in an opensource project like this, team work remains the key to its success. To me, the way the PR found its way into the compiler, suggest either no team existed, or team work was not a priority.

I understand that this is just my view, and not necessarily how it is. But it's my view that matters to me ;-)

On 1/28/2024 1:24 PM, matheus wrote:
> Walter I have a question regarding C, I remember that in the past you wrote a paper about a solution for the C Arrays, which would be something like storing its size in the first address and increment it to be used, and time you want the array size it would do something like:
>   *(p-1) == size.
> 
> Could you please share that paper again?

I'm sorry, I don't recall writing such a paper. They're called length-prefixed strings, which are useful for some cases but not in the general case because they don't support slicing.

I did write a paper about adding D arrays to C:

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

On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:
> On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:
>> I don't know if I am right but part of the motivation of import C seems to have been competition - Zig added the ability to compile C. It seems the idea of import C came up after and maybe as a consequence of this.
>
> I didn't know Zig did that until after I did ImportC.

Zig also has the ability to translate C headers into Zig. The result is very similar to ImportC. I believe I mentioned this to you when ImportC first became available.

I think this is an important capability for both languages. Added to the ability to call C libraries directly, it makes direct access, without binding libraries, to C libraries possible. I think your decision to implement ImportC was a good one.

I've done quite a bit of gtk3 work in Rust. The Rust gtk "crate" is insanely complex and poorly documented (sometimes even inaccurate, where they generate the documentation using snippets from the original gtk3 docs, sometimes including memory-management things that are not necessary in Rust), unlike gtk3 itself. I much prefer working directly with gtk3 in D. I did the D work before ImportC was available, so wrote my own D function prototypes. Even that was preferable to wrestling with the Rust "crate" and I'm sure ImportC would have made the job a lot easier, if it is up to dealing with the gtk header files. I have tried ImportC with sqlite and that works just fine.

On 1/28/2024 7:35 PM, Don Allen wrote:
> Zig also has the ability to translate C headers into Zig. The result is very similar to ImportC. I believe I mentioned this to you when ImportC first became available.

You probably did.


> I think this is an important capability for both languages. Added to the ability to call C libraries directly, it makes direct access, without binding libraries, to C libraries possible. I think your decision to implement ImportC was a good one.
> 
> I've done quite a bit of gtk3 work in Rust. The Rust gtk "crate" is insanely complex and poorly documented (sometimes even inaccurate, where they generate the documentation using snippets from the original gtk3 docs, sometimes including memory-management things that are not necessary in Rust), unlike gtk3 itself. I much prefer working directly with gtk3 in D. I did the D work before ImportC was available, so wrote my own D function prototypes. Even that was preferable to wrestling with the Rust "crate" and I'm sure ImportC would have made the job a lot easier, if it is up to dealing with the gtk header files. I have tried ImportC with sqlite and that works just fine.

I'm glad it's working for you!

D can actually translate C to D, as well. Just add the switch for .di file generation, and the C code will be emitted as D! Adam Wilson prefers to use it this way rather than keep importing the .h files.

I warned Adam that this was imperfect, as C semantics don't exactly line up with D semantics. But he's well aware of that, and it isn't a problem for his work.

On 1/28/2024 8:11 PM, Lance Bachmeier wrote:
> On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:
> 
>> It's fair to consider the result. ImportC elicited more or less no interest from anybody. I expected that. Over time, though, its detractors who have tried it have found it to be a game-changing time saver. ImportC is a huge win for D.
> 
> I wouldn't say "no interest". This is [what I said](https://forum.dlang.org/post/apozoxpxalpdqiysoqak@forum.dlang.org):

Thanks for reminding me! My mind is like a sieve.


>> This will be incredible. I have a lot of use cases for it. In particular on Windows where linking to DLLs is not fun.
> 
> It turns out I was a bit too optimistic. The number of dependencies for the typical C project is huge, including things like glib, so avoiding them isn't usually possible. I also underestimated the widespread use of compiler extensions (thankfully this doesn't seem to be much of a problem any longer for ImportC).

I, too, underestimated the pervasive (and usually quite unnecessary) use of bizarro extensions in the C header files. The majority of the problems with ImportC were(are) these extensions.


> What has worked surprisingly well is converting C headers to D and then using traits to create dynamic bindings at compile time. So while it is not what I originally thought it would be, it's been a win for me in a different way.

You and Adam Wilson! An unanticipated use, for sure.

On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:
> On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:
>> I don't know if I am right but part of the motivation of import C seems to have been competition - Zig added the ability to compile C. It seems the idea of import C came up after and maybe as a consequence of this.
>
> I didn't know Zig did that until after I did ImportC.

When did you start on importC?

https://forum.dlang.org/thread/yocvibzernkchgsbcpyb@forum.dlang.org

On 1/29/2024 1:34 PM, Dibyendu Majumdar wrote:
> On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:
>> On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:
>>> I don't know if I am right but part of the motivation of import C seems to have been competition - Zig added the ability to compile C. It seems the idea of import C came up after and maybe as a consequence of this.
>>
>> I didn't know Zig did that until after I did ImportC.
> 
> When did you start on importC?
> 
> https://forum.dlang.org/thread/yocvibzernkchgsbcpyb@forum.dlang.org

That post was Dec 3, 2020. The PR for ImportC was May 9, 2021, about 5 months later. When did I start ImportC? I don't recall. I don't recall reading that thread, either, I don't read all the messages, and am generally not interested in detailed comparisons of D with other languages (as it is an endless timesink).

I also was never sure if Zig could actually import C files, or was just able to fork a C compiler and link to the result. But this clears it up:

```C
const c = @cImport(@cInclude("soundio/soundio.h"));
```

https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings

D's syntax is better:

```d
import soundio;
```

ImportC grew out of my discussions with Atila about dpp.

On Tuesday, 30 January 2024 at 00:57:31 UTC, Walter Bright wrote:

> https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings
>
> D's syntax is better:

Well the syntax is cleaner but has the potential to be ambiguous both with .d files and the usual <> vs "" stuff.