December 22, 2022
On 12/21/2022 11:18 AM, Walter Bright wrote:
> On 12/21/2022 11:09 AM, Walter Bright wrote:
>> https://news.ycombinator.com/edit?id=34084894
>>
>> I'm wondering. Should I just go ahead and implement [..] in #ImportC?
> 
> Vote here:
> 
> https://twitter.com/WalterBright/status/1605642794965483521

Stunning poll results just in:

41.6% yes
29.2% no
 0.0% MS syntax is better
29.2% Hal needs to open the pod bay doors
December 23, 2022
On Thursday, 22 December 2022 at 22:45:40 UTC, Walter Bright wrote:
>  0.0% MS syntax is better

At least we can all agree on one thing, the MS syntax is horrid :^)
December 22, 2022
On 12/22/2022 4:08 PM, Greggor wrote:
> On Thursday, 22 December 2022 at 22:45:40 UTC, Walter Bright wrote:
>>  0.0% MS syntax is better
> 
> At least we can all agree on one thing, the MS syntax is horrid :^)

One reason I get paid the Big Bucks!
December 23, 2022
On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> https://news.ycombinator.com/edit?id=34084894
>
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

So, presumably you have read all 173 pages of the Checked C draft??

(i.e. there's more to it than just '_Array_ptr<int> p : count(5) = a; )

https://github.com/microsoft/checkedc/releases/download/CheckedC-Clang-12.0.1-rel3/checkedc-v0.9.pdf

173 pages - to talk about how they want to fix bounds checking problems in C.

I can learn the entire C langauge in less than 1/10 of that number of pages.

December 23, 2022

On Thursday, 22 December 2022 at 21:18:04 UTC, Walter Bright wrote:

>

On 12/22/2022 2:21 AM, Iain Buclaw wrote:

>

Which no one will ever use. :-)

They were very useful for the ImportC test suite.

It's still a DMD folly. GDC has been able to compile C files since day 0 (19 years ago?) as it delegates foreign sources to the other compilers it was built with - the reverse also works, GCC can compile D sources because it uses the same mechanism. So you could say that C and C++ have been capable of compiling D sources since 2019. ;-)

$ gccgo -fno-druntime compiler/test/runnable/bcraii.d -o go-bcraii
$ ./go-bcraii
S.this()
S.~this()
inside

None of these tests where dmd pretends to be a C compiler even work outside of dmd.

$ gdc compiler/test/compilable/cimport.c
compiler/test/compilable/cimport.c:3:1: error: unknown type name ‘__import’
    3 | __import core.stdc.stdarg;
      | ^~~~~~~~
compiler/test/compilable/cimport.c:3:14: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
    3 | __import core.stdc.stdarg;
      |              ^
compiler/test/compilable/cimport.c:4:1: error: unknown type name ‘__import’
    4 | __import imports.impcimport;
      | ^~~~~~~~
compiler/test/compilable/cimport.c:4:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
    4 | __import imports.impcimport;
      |                 ^
compiler/test/compilable/cimport.c: In function ‘foo’:
compiler/test/compilable/cimport.c:8:5: error: unknown type name ‘va_list’
    8 |     va_list x;
      |     ^~~~~~~
compiler/test/compilable/cimport.c:1:1: note: ‘va_list’ is defined in header ‘<stdarg.h>’; did you forget to ‘#include <stdarg.h>’?
  +++ |+#include <stdarg.h>
    1 | // https://issues.dlang.org/show_bug.cgi?id=22666
compiler/test/compilable/cimport.c:9:16: error: ‘A’ undeclared (first use in this function)
    9 |     return 1 + A;
      |                ^
compiler/test/compilable/cimport.c:9:16: note: each undeclared identifier is reported only once for each function it appears in

DMD becoming a C compiler is a side-effect of importC, but just because you can doesn't mean you should.

December 23, 2022
On Thursday, 22 December 2022 at 21:18:04 UTC, Walter Bright wrote:
> On 12/22/2022 2:21 AM, Iain Buclaw wrote:
>> Which no one will ever use. :-)
>
> They were very useful for the ImportC test suite.

What you are saying is, ImportC is only useful for, well, ImportC.

I'm sorry, but I can't understand your game here. A few posts back you're saying:
> Versioning comes with other problems. The most significant is we lack sufficient staff to maintain multiple versions.
Yet, for maintaining multiple obscure dialects of D there IS enough staff? So, is there enough, or is there not?

There's D, there's worseD ("better" C if you want). Now there's evenWorseD, which is basically going back straight to C. And I picked D specifically because I wanted to break free from C/C++.

What is your goal even, do you care about D at all? I'm going to great lengths to write software that's pure D, and when the creator of D gives up and starts "fixing" other languages, that's a huge off point to many.
December 23, 2022
On Friday, 23 December 2022 at 14:24:36 UTC, GrimMaple wrote:

> What is your goal even, do you care about D at all? I'm going to great lengths to write software that's pure D, and when the creator of D gives up and starts "fixing" other languages, that's a huge off point to many.

Yes.

This episode prompted me to do some reading about the history of this project. Around the time Andrei Andreescu left the project, he wrote a pretty frank message about the state of the D world then and what he thought was needed. This prompted an exchange of messages with others interested in D. My point in bringing this up is that that exchange makes what has happened here feel like deju-vu all over again. Nothing has changed.

I don't think anyone in their right mind would question Walter's knowledge of compilers, his technical chops. But knowing how to make compilers does not qualify a person to manage a complex software project and set its agenda. This requires different talents. It is what the Peter Principle is all about. I speak from experience here, including my own mistakes in a long career of writing code and managing development projects. I was far better at the former than the latter and I think the same can be said of Walter. Reading the Andreescu thread demonstrates that I am not the first to make this observation.

The issues with this project's decision-making have exactly the effect you cite. It has had a direct effect on my own confidence in this project. I'm building software for my family to use without me, when that time comes, and it now feels to me like a key component that I'm relying on comes from a dysfunctional family. For that reason, I've decided to fall back on my original C version and bring it up-to-date (including back-porting some of my D code). I have more confidence in the stability of the C environment and its tools, despite the primitive state of the language compared to D.

I do hope this project finally finds a way to right itself. It will take the addition of the right person or people, not an easy task, but not impossible. Good luck.




December 23, 2022

On Friday, 23 December 2022 at 14:24:36 UTC, GrimMaple wrote:

>

What is your goal even, do you care about D at all? I'm going to great lengths to write software that's pure D, and when the creator of D gives up and starts "fixing" other languages, that's a huge off point to many.

https://idioms.thefreedictionary.com/kills+your+darlings

Many a writer faces the uncomfortable need to kill their darlings in the editing process. If something in your art is no longer working, then you'll have to be ruthless and kill your darlings. How else will you grow as an artist?

December 23, 2022
On Friday, 23 December 2022 at 16:51:40 UTC, Don Allen wrote:
> 
> I do hope this project finally finds a way to right itself. It will take the addition of the right person or people, not an easy task, but not impossible. Good luck.

I believe the main hope is with forks or new compiler projects
December 23, 2022

On Friday, 23 December 2022 at 17:06:51 UTC, IGotD- wrote:

>

https://idioms.thefreedictionary.com/kills+your+darlings

Many a writer faces the uncomfortable need to kill their darlings in the editing process. If something in your art is no longer working, then you'll have to be ruthless and kill your darlings. How else will you grow as an artist?

Is D compiler supposed to be a practical tool or a piece of art?