On 5/14/2023 1:21 AM, IGotD- wrote:
> I thought it was C++ you wanted to leverage.

I knew back then the impracticality of importing C++ code.


> You keep mention on this forum that you keep on hitting corner cases with importC which s expected. C is old and there many quirks, non-standard and compiler specific code out there. I would still gone the converter route as it would instead translate the .h file to native D which you then can use natively within D.

We've had 3 converters so far.

> For example you haven't enabled C macros to be used within D, with a converter you could have converted the macro to D code (mixin?). I think that would have scaled better than trying to retrofit a C compiler into D compiler. 

There are a number of C features which do not translate into D. But with ImportC I can make them work seamlessly.

> Also why should C be a first class citizen and not C++, Rust etc.

C is the lingua franka, not C++ or Rust.

> Since there
> are plenty of languages out there a converter project for each language is more
> convenient.

I can only do so much.


> I'm a bit afraid that importC will be a feature that needs constant patching and consume time.

C changes a lot slower than other languages.

On 5/14/2023 4:39 PM, jmh530 wrote:
> Is ImportC the final destination? Or is ImportC a step along the way to a final destination?

Not sure what you mean. It is an end in itself.

On Sunday, 14 May 2023 at 23:57:32 UTC, Walter Bright wrote:
> On 5/14/2023 4:39 PM, jmh530 wrote:
>> Is ImportC the final destination? Or is ImportC a step along the way to a final destination?
>
> Not sure what you mean. It is an end in itself.

You said before: "But D itself cannot read C .h files nor .c files (a capability that C++ has and has used to great advantage)"

importC lets you import .c file in D, but not a .h file. To import a .h file in D, I have to create a .c file and include only the .h file header and then import the .c file. Would you be able to streamline that further so that the .h file can be imported?

Maybe behind the scenes, it would look for a .d file, then a .c file, then try to create a blank .c file and include a .h? I don't know what makes the most sense, but think about it this way: for me to say some random C library works for D, I need to create a separate project for it with a .c file that includes the .h. If you can import the .h file directly, then it would just work (TM).

On 5/15/2023 5:20 AM, jmh530 wrote:
> importC lets you import .c file in D, but not a .h file. To import a .h file in D, I have to create a .c file and include only the .h file header and then import the .c file. Would you be able to streamline that further so that the .h file can be imported?

The .h file limitation is due to a disagreement between myself and Iain about the best way forward for it.

On Sunday, 14 May 2023 at 23:56:55 UTC, Walter Bright wrote:
>
> There are a number of C features which do not translate into D. But with ImportC I can make them work seamlessly.

What are the C features that cannot be expressed in D?

On Monday, 15 May 2023 at 20:19:05 UTC, IGotD- wrote:
> On Sunday, 14 May 2023 at 23:56:55 UTC, Walter Bright wrote:
>>
>> There are a number of C features which do not translate into D. But with ImportC I can make them work seamlessly.
>
> What are the C features that cannot be expressed in D?

VLA's and flexible arrays.

On Tuesday, 16 May 2023 at 07:48:42 UTC, Patrick Schluter wrote:
> On Monday, 15 May 2023 at 20:19:05 UTC, IGotD- wrote:
>>
>> What are the C features that cannot be expressed in D?
>
> VLA's and flexible arrays.

A C flexible array can be translated to a slice. I have done this myself and was amused how good fit it was. In 99% of the cases there is some upper limit for the flexible array and a slice is an extra guard against out of bounds accesses that C doesn't have.

VLA should be a part of the FFI and not importC.

The only thing I can think of that isn't supported are bitfields. The question is if this could have been solved with meta programming.

On Tuesday, 16 May 2023 at 11:04:53 UTC, IGotD- wrote:
> The only thing I can think of that isn't supported are bitfields. The question is if this could have been solved with meta programming.

Bit fields are already something that's provided in Phobos: https://dlang.org/phobos/std_bitmanip.html#bitfields

I can't attest to how good they are, but I think it's the right approach; rather choose to implement something in the std lib than the language itself to avoid unnecessary complexity.

On Tuesday, 16 May 2023 at 11:04:53 UTC, IGotD- wrote:
> The only thing I can think of that isn't supported are bitfields. The question is if this could have been solved with meta programming.

ImportC can do C bitfields, but since they're layout is undefined it is useless anyway.

(Walter also copied importC's awful bitfields into D, but I hope that mistake is reverted.)

On Monday, 15 May 2023 at 19:13:49 UTC, Walter Bright wrote:
> On 5/15/2023 5:20 AM, jmh530 wrote:
>> importC lets you import .c file in D, but not a .h file. To import a .h file in D, I have to create a .c file and include only the .h file header and then import the .c file. Would you be able to streamline that further so that the .h file can be imported?
>
> The .h file limitation is due to a disagreement between myself and Iain about the best way forward for it.

I hope some agreement is reached.

Looking over the (multiple) github discussions, I was partial to the solution of `import "foo.h"` combined with a custom search path for `.h` files [1]. The one to use `import("foo.h")` looks a bit too much like an import expression.

You made a comment about the import syntax getting kludged [2], but it would be a little less kludge-y if you could import any file like `import "foo.d"` or `import "foo.c"`, but then only allow .d/.c/.i files to be imported like `import foo`. Further, I recall you previously commenting on how sometimes you have to make the compiler more complicated in order to make things work how users expect them to. This might be a situation like that. Though I can't say what the best solution is, I think most would agree that it would be good to have something better than creating a .c file to import a .h file.

Not a lot of code has been written yet that uses importC so there is still time to get it right.

[1] https://github.com/dlang/dmd/pull/14700
[2] https://github.com/dlang/dmd/pull/14864#issuecomment-1432256522