On Thursday, 13 May 2021 at 00:04:38 UTC, Walter Bright wrote:
> On 5/12/2021 2:24 AM, xBuzz wrote:
>> [...]
>
> I don't mind. But I will say that show me a language that isn't getting a constant stream of bug fixes, improvements, etc., and I'll show you a dead language.
>
> [...]

+1

On Friday, 14 May 2021 at 02:04:47 UTC, Adam D. Ruppe wrote:
> This is already fairly easy to do. dub isn't great at it, but you can use a pre-build command in the dub settings to run make (or whatever) to build your C parts, then the D parts are built and they link seamlessly.

Its easy to do so long as the tools you need are available on every platform you target.  On Linux this trivial, but Windows is a different beast.  Even the download URL for Windows build tools seems to move around all the time.  And once the build tools are installed, there's no one obvious location for nmake.exe and cl.exe.  Just getting dub to reliably find those tools on some random person's computer is difficult.  On the other hand, dub can usually find dmd.

Also the dmd+dub distribution is so easy to install that I would be happy to depend on it just to get away from nmake.exe & cl.exe.

> You can maintain your bindings by hand, or use dstep to build D bindings from C headers 90%ish reliably and dtoh to build C bindings from D files even better. It isn't actually that hard to do, but it can indeed be annoying if there's frequent changes to the interface.

Maybe I'm just unlucky (or doing it wrong) but I've never had dstep or htod work without customizing the output by hand.  They are a good first step and a very welcome time saver but (so far at least) I wouldn't want to distribute C sources and hope that header parsing works.

If the dmd distribution came with a real C preprocessor and dmd gained the ability to compile most C code, I think the end result would be more user friendly, especially on Windows.  I know I'd try it out.

On Friday, 14 May 2021 at 03:03:04 UTC, Chris Piker wrote:
> On Linux this trivial, but Windows is a different beast.

You wanna run it from the x86 native tools for VS command prompt window, then the PATH is set up for it.

But yeah I do agree it is quite a bit of a pain. Personally, I've actually ported full C files to D before to avoid having to deal with it (see stuff like jpeg.d and stb_ttf.d in my arsd repo as some examples - though i had help with those too).

> Maybe I'm just unlucky (or doing it wrong) but I've never had dstep or htod work without customizing the output by hand.

Well this is what I mean by 90% reliable - you do have to do the other 10% by hand. But still that's not too bad.

And tbh I rarely even do that, I just make C bindings as i need them by hand.

> If the dmd distribution came with a real C preprocessor and dmd gained the ability to compile most C code, I think the end result would be more user friendly, especially on Windows.  I know I'd try it out.

Yea, there is definitely potential here in making it easier.

Just like if you're willing to spend a few hours doing some boring tedium up front it can be done right now too.

On 5/13/2021 2:04 PM, Iain Buclaw wrote:
> Well, either one of, or two things will happen:
> 
> 1. People will raise bugs against dmd because `gdc foo.c` will be able to compile more code than dmd (and do preprocessing).
> 
> 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d` doesn't inline C functions into bar.
> 
> I meant conflicts will happen if I change the current behavior so make it so the D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.

Understood.

It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it.

https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax

There's some wishy-washy wording:

"Where an attribute specifier is applied to a parameter declared as a function or an array, it should apply to the function or array rather than the pointer to which the parameter is implicitly converted, but this is not yet correctly implemented."

"In some other cases, attribute specifiers are permitted by this grammar but not yet supported by the compiler."

"At present, ..."

"An attribute specifier list may, in future, be permitted ..."

"at present this is not implemented and they are ignored"

"some laxity is allowed in the placing of attributes"

which is discouraging. There are the other extensions, too.

Ironically, the one gcc extension ImportC can support fully is inline assembler :-) as you've already seen to that!

The plan is to do as few gcc C extensions as practical.

As for the user having options, that's why we have multiple D compilers. ImportC isn't part of the D language, and so differing flavors of C support is within reason.

On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
> On 5/13/2021 2:04 PM, Iain Buclaw wrote:
>> Well, either one of, or two things will happen:
>> 
>> 1. People will raise bugs against dmd because `gdc foo.c` will be able to compile more code than dmd (and do preprocessing).
>> 
>> 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d` doesn't inline C functions into bar.
>> 
>> I meant conflicts will happen if I change the current behavior so make it so the D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.
>
> Understood.
>
> It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it.
>
> https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
>
> There's some wishy-washy wording:
>
> "Where an attribute specifier is applied to a parameter declared as a function or an array, it should apply to the function or array rather than the pointer to which the parameter is implicitly converted, but this is not yet correctly implemented."
>
> "In some other cases, attribute specifiers are permitted by this grammar but not yet supported by the compiler."
>
> "At present, ..."
>
> "An attribute specifier list may, in future, be permitted ..."
>
> "at present this is not implemented and they are ignored"
>
> "some laxity is allowed in the placing of attributes"
>
> which is discouraging. There are the other extensions, too.
>
> Ironically, the one gcc extension ImportC can support fully is inline assembler :-) as you've already seen to that!
>
> The plan is to do as few gcc C extensions as practical.
>
> As for the user having options, that's why we have multiple D compilers. ImportC isn't part of the D language, and so differing flavors of C support is within reason.

Recognizing the syntax and doing nothing would he enough for quite a few libraries. For GNU stdio.h to work I had to clean out a bunch of attributes, asm, and any structs, but other than that it did seem to work.

The only other that I can say is that keep in mind that the blocker is using C not compiling C. I don't want dmd to be my C compiler - so you only need to understand GNU extensions that are used in header files (and don't appear in inline functions in those headers, but still).

On Wednesday, 12 May 2021 at 15:22:08 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 12 May 2021 at 14:41:17 UTC, Andre Pany wrote:
> I don't think the people who have left did it because of C interop. C++ interop maybe.  People who left most likely did it because of inconsistencies and memory management challenges.

I'm only one data point, and maybe in the extreme minority, but
in my field C++ interop, GC reliance, and language inconsistencies
aren't critical issues.

In fact many of our widely used languages are riddled with
inconsistencies (I'm looking at you matlab & idl), but that
doesn't stop them because the feature set is so nice.

All the widely used libraries are written in C or Fortran, and
most of our local legacy code is in C, or Python.  This means
C++ interop really isn't part of our picture.  Since D can
call C and it can look very pythonic it's a good fit.

So for us, improved C interop would be a nice bonus, and a good
selling point.

(Heck if you really want to turn some heads add a fortran 77 parser :)

On Friday, 14 May 2021 at 06:38:34 UTC, Chris Piker wrote:
> In fact many of our widely used languages are riddled with
> inconsistencies (I'm looking at you matlab & idl), but that
> doesn't stop them because the feature set is so nice.

Right, but Matlab is being displaced by Python (at a slow pace). Of course that is also related to licensing (for students), but I think language-issues is also a factor. Especially when writing larger programs, then Python is a clear winner.

> So for us, improved C interop would be a nice bonus, and a good
> selling point.

Sure! BUT you also didn't dismiss D as a valid tool for you, am I right?