On 5/12/2021 2:24 AM, xBuzz wrote:
> I'm gonna say something you don't like.

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.

Every D changelog is full of bug fixes and improvements.

The true measure of a language its not its perfection, but its utility. Is D usable to easily create great programs? Hell yes!

The only perfect languages are very small ones, and nobody uses them, because you can't do anything with them. The real world is dirty, and useful languages wind up being dirty to be able to play in the real world.

As for ImportC, people have been asking for easy importation of C code for decades. D's inability to do that is very clearly a large barrier to adoption. I hear about this *all* the time.

I decided to take a sledgehammer and bash that problem out of existence. It's absolutely what the D community ought to be doing.

On 5/12/2021 6:01 AM, Adam D. Ruppe wrote:
> On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
>> If you could add a C compiler to dmd with 3000 lines of code,
> 
> As of the time of this writing it has already grown to:
> 
> https://github.com/dlang/dmd/pull/12507
> 
> +3,905 −42
> 
> 30% overbudget just three days after the announcement. I stand by my prediction that this is going to end up a LOT bigger than it looked at first.

LOL. Subtract out the changelog documentation, and all the comments.

On 5/12/2021 6:08 AM, deadalnix wrote:
>  From the PR
>> WalterBright added the Trivial label 3 days ago
> 
> Found it funny.
> 
> C is not a fast moving target, so this is probably worth doing.

While adding the Trivial label was indeed my little joke, it's not entirely wrong. C is a small and very well understood language, so implementing a compiler for it doesn't require much cleverness. I've also gone around the horn implementing a C compiler before, and learned to take the canal this time.

On 5/12/2021 7:00 AM, IGotD- wrote:
> On Wednesday, 12 May 2021 at 11:39:33 UTC, Igor Shirkalin wrote:
>>
>> years ago. I'd not stop on the latest C ISO, I'd add more featurs from C++.
>>
> 
> I'm thinking in the same lines. It would be nice if importC would be able to detect abstract C++ classes and convert them to extern(C++) interfaces. Then we have inheritance support to think of as well.
> 
> This proposal has a tendency to grow. It might be a useful tool and people will demand more of it all the time if it becomes popular. Implementing importC will open that can of worms.

Just think - if it was so successful people want more out of it, that is a good thing!

On 5/12/2021 4:24 AM, Iain Buclaw wrote:
> Integration is another matter though, as all GCC compilers know about all languages that have been enabled, and what file extensions they handle.  i.e: `gdc foo.c bar.d baz.go` will invoke the C, D and Go compilers separately in one execution step:
> ```
> cpp foo.c -o foo.i;
> cc1 foo.i -o foo.o;
> d21 bar.d -o bar.o;
> go1 baz.go -o baz.o;
> ld foo.o bar.o baz.o -o a.out
> ```

I don't see any conflict there, either. While

    dmd foo.c

will compile C and generate an executable, so will

    gdc foo.c

It'll just use a different C compiler.

On Thursday, 13 May 2021 at 00:11:58 UTC, Walter Bright wrote:
> On 5/12/2021 6:08 AM, deadalnix wrote:
>>  From the PR
>>> WalterBright added the Trivial label 3 days ago
>> 
>> Found it funny.
>> 
>> C is not a fast moving target, so this is probably worth doing.
>
> While adding the Trivial label was indeed my little joke, it's not entirely wrong. C is a small and very well understood language, so implementing a compiler for it doesn't require much cleverness. I've also gone around the horn implementing a C compiler before, and learned to take the canal this time.

Sequence points, volatile, shared memory model, undefined behavior, obscure aliasing rules... C is small and well understood indeed -- when you chose to ignore all these things that happen to contradict your narrative.

On Wednesday, 12 May 2021 at 21:44:29 UTC, Jordan Wilson wrote:
> I think it's possible to have people who left and people who join can have very little to do with each other.

If they joined for the wrong reasons, but D was initially "marketed" as a better C++, and only a small set of those early adopters are here still, so...

Anyway, integration with C by translating to the D AST is something I did strongly suggest years ago in these forums, so I am not complaining about the feature.

I only worry about existing ongoing efforts be significantly delayed. Like if refactoring the AST is desirable, then it better be done before this C-addition is merged in...

On Thursday, 13 May 2021 at 06:56:07 UTC, Araq wrote:
> Sequence points, volatile, shared memory model, undefined behavior, obscure aliasing rules... C is small and well understood indeed -- when you chose to ignore all these things that happen to contradict your narrative.

The goal of D is that tranlating C-code to D should be easy so D should adopt the sequence points and shared memory model of C/C++ anyway. Undefined behaviour is not relevant, as that means the compiler can define it any way it wants to as such code is not valid (should not be provided by the programmer), volatile is not frequently used outside embedded/kernel programming (and isn't difficult to implement anyway).

On 5/11/21 10:34 AM, Steven Schveighoffer wrote:
> I had this idea: what if in D code, you can access CPP macros explicitly. Like:
> 
> #CMACRO(<macro expression)

Hm... macro is still a reserved keyword, so we could use that also.

-Steve

On 5/12/2021 11:56 PM, Araq wrote:
> Sequence points, volatile, shared memory model, undefined behavior, obscure aliasing rules... C is small and well understood indeed -- when you chose to ignore all these things that happen to contradict your narrative.

Essentially none of that matters except sequence points for ImportC. And D follows the same sequence point rules.