On 5/13/2022 10:27 AM, H. S. Teoh wrote:
> As for #define'd manifest constants, wouldn't it just be a matter of
> adding a separate pass over the .h file to extract #define's that look
> like they can be transformed into enum constants?  Shouldn't be *that*
> hard to do, in theory anyway.

cpp and cl all have the ability to emit all the macro definitions to stdout at the end of a run. (I intend to add it to sppn.) The idea is to intercept that output, look for #define patterns we can deal with, and deal with them.

It's straightforward, it will just take some coding.

On 5/13/2022 10:35 AM, IGotD- wrote:
> There must be a similar way as with C compilers (the -D command line option) to inject defines. The D compiler must add this so that import C constants can be defined at the command line otherwise we have that extra custom build step again.

The plan is to add a switch to dmd that passes command line options on to the preprocessor. Just like what dmd does to pass such to the linker.

On 5/13/2022 6:30 AM, Daniel N wrote:
> For me ImportC is *the* killer feature. Currently at work we simply change 1 file from *.c to *.cc fix a few compile-errors and done, this is why C++ became what it is, if D had this from day-1 then I think it would have been a huge success, I can only hope dlang added this feature in time to still succeed, many other languages are starting to catch up.
> 
> I have zero interest in adding custom build steps in exotic build systems to generate bindings, nor is it possible to generate static bindings because all other teams update their *.h files daily and we need to be able to use the new features without manual steps.
> 
> Now, if you argue that custom build steps is no big thing, then why is CTFE so awesome? No custom build steps, that's why!

That's exactly the point.

On 5/13/2022 10:33 AM, Daniel N wrote:
>> ... but import C require a custom build step today to remove all preprocessor text from the .h file. You must have zero interest in import C in that case.
> 
> It's work in progress, it will work in the future.

It works today (on master).

On 5/13/2022 11:22 AM, Adam D Ruppe wrote:
> On Friday, 13 May 2022 at 18:17:06 UTC, Walter Bright wrote:
>> htod, dstep and dpp suggest otherwise.
> 
> What shortcomings did you see in those, and how does ImportC solve them?

The fact that there are 3 of them suggests shortcomings.

ImportC can:

1. handle C constructs that don't have D equivalents, such as bitfields and _Generic (yes, I did recently add the bitfields to D).

2. inline C functions

3. do CTFE on C functions

4. D and C source files can be handed to the dmd command line

5. no special syntax for importing C files

6. can be used as a straightforward C compiler

7. import D code (!)

8. minimizes friction in the build system

9. do inline assembler (well, D style inline assembler, not gcc/cl/dmc style)

10. generate linkable libraries from C code

11. make it easy to incrementally convert C code to D

13. make mixing and matching D and C code almost trivial

On Friday, 13 May 2022 at 19:18:35 UTC, Walter Bright wrote:
>
> The fact that there are 3 of them suggests shortcomings.
>
> ImportC can:
>
> 1. handle C constructs that don't have D equivalents, such as bitfields and _Generic (yes, I did recently add the bitfields to D).
>
> 2. inline C functions
>
> 3. do CTFE on C functions
>
> 4. D and C source files can be handed to the dmd command line
>
> 5. no special syntax for importing C files
>
> 6. can be used as a straightforward C compiler
>
> 7. import D code (!)
>
> 8. minimizes friction in the build system
>
> 9. do inline assembler (well, D style inline assembler, not gcc/cl/dmc style)
>
> 10. generate linkable libraries from C code
>
> 11. make it easy to incrementally convert C code to D
>
> 13. make mixing and matching D and C code almost trivial

Nice, but I will give you a challenge. You are going to write a Linux driver in D (or better C) and you are only allowed to import C the necessary header files like <linux/kernel.h>, <linux/init.h> etc.

On Friday, 13 May 2022 at 19:18:35 UTC, Walter Bright wrote:
> ...
>
> 11. make it easy to incrementally convert C code to D
>
> 13. make mixing and matching D and C code almost trivial

on 11. ImportC will actually dissuade people from moving away from C.

on 13. This too will dissuade people from moving away from C.

In essence, you're forever locking C into D. C++ made this mistake too.

On Friday, 13 May 2022 at 23:24:14 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 13 May 2022 at 22:49:09 UTC, forkit wrote:
>> In essence, you're forever locking C into D. C++ made this mistake too.
>
> Yes, but that decision has been there all the time by keeping weird things from C such as messy operator precedence.
>
> I am more concerned about compiler internals and refactoring.
>
> (D's biggest mistake was to not align semantics with C++ and incorporate clang for C++ interop, but that is too late now.)

I think 'why is D unpopular' can be answered by D's biggest mistake.

Which was, to not move away from C (i.e. differentiate itself from C).

Instead, it tries to offer you the future, while being tied to the past.

On 5/13/2022 12:43 PM, IGotD- wrote:
> Nice, but I will give you a challenge. You are going to write a Linux driver in D (or better C) and you are only allowed to import C the necessary header files like <linux/kernel.h>, <linux/init.h> etc.

I'll let you do that, and please post any issues you find to bugzilla.