• Walter Bright (3/3) Jan 16 2022 https://github.com/dlang/dmd/pull/13539
• Paul Backus (21/24) Jan 16 2022 What's the intended use-case for this? If I'm using ImportC to
• Walter Bright (2/3) Jan 16 2022 You no longer need dtoh if you're using ImportC.
• Dave P. (4/7) Jan 16 2022 Next, add syntax for D slices to importC so we can cite the D
• jmh530 (3/6) Jan 16 2022 Would it be possible to have a block of ImportC code in D code?
• Walter Bright (4/6) Jan 16 2022 I had thought of that, as I've done gradual conversions myself. But usin...
• James Lu (4/7) Jan 27 2022 This dialect of C- what if it was called C+, and was a superset?
• forkit (2/5) Jan 27 2022 just call it: DC

Walter Bright <newshound2 digitalmars.com> writes:

https://github.com/dlang/dmd/pull/13539

Yes, real, live modules!

(I can hardly believe this works!)

Paul Backus <snarwin gmail.com> writes:

On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)

What's the intended use-case for this? If I'm using ImportC to 
import the header file for an existing C library, it's not going 
to contain a D-specific feature like this. If I'm writing a new 
library, and I want it to be usable from C, I can't use __import 
in the header file, because my C compiler won't recognize it. And 
if I only want my library to be usable from D, then I can just 
write a D module, and use a normal D import statement.

I guess it makes it possible to write code like this:

     /* example.h */
     #ifdef __IMPORTC__
     __import code.stdc.stdio;
     #else
     #include <stdio.h>
     #endif

     void example(void) { puts("example"); }

...but I'm struggling to see what advantages an example like the 
above has compared to the status quo. Slightly faster compile 
times, because __import is faster to process than #include? Less 
namespace pollution, because imported symbols aren't visible 
outside of the C header but #included symbols are?

Walter Bright <newshound2 digitalmars.com> writes:

On 1/16/2022 6:55 AM, Paul Backus wrote:
 What's the intended use-case for this?

You no longer need dtoh if you're using ImportC.

Dave P. <dave287091 gmail.com> writes:

On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)

Next, add syntax for D slices to importC so we can cite the D 
compiler as prior art and finally get dynamic arrays that know 
their length into standard C. ;)

jmh530 <john.michael.hall gmail.com> writes:

On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)

Would it be possible to have a block of ImportC code in D code? 
For instance for people gradually converting C code to D code.

Walter Bright <newshound2 digitalmars.com> writes:

On 1/16/2022 2:31 PM, jmh530 wrote:
 Would it be possible to have a block of ImportC code in D code? For instance
for 
 people gradually converting C code to D code.

I had thought of that, as I've done gradual conversions myself. But using 
version's on the D side and #if on the C side works well enough, and I'd hate 
for it to be more than a temporary state of the code.

James Lu <jamtlu gmail.com> writes:

On Sunday, 16 January 2022 at 09:47:00 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/13539

 Yes, real, live modules!

 (I can hardly believe this works!)

This dialect of C- what if it was called C+, and was a superset? 
C with some D features.

Just needs a preprocessor.

forkit <forkit gmail.com> writes:

On Friday, 28 January 2022 at 02:56:02 UTC, James Lu wrote:
 This dialect of C- what if it was called C+, and was a 
 superset? C with some D features.

 Just needs a preprocessor.

just call it: DC