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

I love making discoveries of emergent behavior like this! It's certainly saved me a lot of work.

On Thursday, 11 May 2023 at 18:11:32 UTC, Walter Bright wrote:
> https://twitter.com/WalterBright/status/1656574787874095104
>
> I love making discoveries of emergent behavior like this! It's certainly saved me a lot of work.

Interesting, yes... or at least.. perhaps.

But personally, I think the D language's obsession with the C language.. has already gone too far.

Rust and Swift are showing where languages should be heading.

On Thursday, 11 May 2023 at 22:08:30 UTC, Coco wrote:
> On Thursday, 11 May 2023 at 18:11:32 UTC, Walter Bright wrote:
>> https://twitter.com/WalterBright/status/1656574787874095104
>>
>> I love making discoveries of emergent behavior like this! It's certainly saved me a lot of work.
>
> Interesting, yes... or at least.. perhaps.
>
> But personally, I think the D language's obsession with the C language.. has already gone too far.
>
> Rust and Swift are showing where languages should be heading.


Couldn't help but observe that

D started as better Java by aot compiling similar code

Then D wanted to become better C++ with ranges, structs instead of classes, nogc, etc

Now D wants to be betterC, C extension, etc

Future: D as better assembly

/s
:-)

On 5/12/2023 3:07 PM, user wrote:
> Future: D as better assembly

It already is. D has a better assembler than Gnu, and VC doesn't even have an assembler.

Perhaps I haven't clarified the purpose of ImportC.

D was designed from the beginning to leverage off of existing C code. D's foreign function interface with C is excellent.

But D itself cannot read C .h files nor .c files (a capability that C++ has and has used to great advantage). .h files must be laboriously converted to D. We've done a lot of the usual system .h files conversions, such as core.stdc.stdio, they are in druntime.

The Deimos project is to collect crowd-sourced conversions of C .h files.

The fundamental problem with hand conversions is they are tedious, boring work that nobody wants to do. They also need redoing whenever the vendor of the .h file changes them. As the D community grows, this simply does not scale.

Then there were three attempts at programmatic conversion of .h to .d files, one written by me, one by Jacob, and one by Atila. Those brought us to 3rd base.

To do a home run, the compiler needs to understand C code directly - this is ImportC.

Using D as an extension language for ImportC enabled me to easily get working a number of C features (such as variadic arguments) that would otherwise have required a fair chunk of explicit code to implement. Instead, I was able have it use D's existing implementation code (which is non-trivial) in core.stdc.stdarg.

I.e. ImportC is an enabler of D use.

On Saturday, 13 May 2023 at 18:09:33 UTC, Walter Bright wrote:
> On 5/12/2023 3:07 PM, user wrote:
>> Future: D as better assembly
>
> […]
> Using D as an extension language for ImportC enabled me to easily get working a number of C features (such as variadic arguments) that would otherwise have required a fair chunk of explicit code to implement. Instead, I was able have it use D's existing implementation code (which is non-trivial) in core.stdc.stdarg.
>
> I.e. ImportC is an enabler of D use.

Unfortunately for that example, dmd’s implementation of c varargs is buggy.
https://issues.dlang.org/show_bug.cgi?id=23409

On Saturday, 13 May 2023 at 18:09:33 UTC, Walter Bright wrote:
>
> D was designed from the beginning to leverage off of existing C code. D's foreign function interface with C is excellent.
>

I thought it was C++ you wanted to leverage.

> But D itself cannot read C .h files nor .c files (a capability that C++ has and has used to great advantage). .h files must be laboriously converted to D. We've done a lot of the usual system .h files conversions, such as core.stdc.stdio, they are in druntime.
>
> The Deimos project is to collect crowd-sourced conversions of C .h files.
>
> The fundamental problem with hand conversions is they are tedious, boring work that nobody wants to do. They also need redoing whenever the vendor of the .h file changes them. As the D community grows, this simply does not scale.
>
> Then there were three attempts at programmatic conversion of .h to .d files, one written by me, one by Jacob, and one by Atila. Those brought us to 3rd base.
>
> To do a home run, the compiler needs to understand C code directly - this is ImportC.
>

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. 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. Also why should C be a first class citizen and not C++, Rust etc. Since there are plenty of languages out there a converter project for each language is more convenient.

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

On Saturday, 13 May 2023 at 18:09:33 UTC, Walter Bright wrote:
> [snip]
> Perhaps I haven't clarified the purpose of ImportC.
>
> D was designed from the beginning to leverage off of existing C code. D's foreign function interface with C is excellent.
>
> But D itself cannot read C .h files nor .c files (a capability that C++ has and has used to great advantage). .h files must be laboriously converted to D. We've done a lot of the usual system .h files conversions, such as core.stdc.stdio, they are in druntime.
>
> [snip]
>
> To do a home run, the compiler needs to understand C code directly - this is ImportC.
> [snip]

Is ImportC the final destination? Or is ImportC a step along the way to a final destination?