On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright wrote:

> But to address your point, ImportC has been a big success for D.

Show me any project that successfuly uses ImportC, or didn't happen.

> I appreciate any help identifying specific problems and reporting them on bugzilla.

And then reverting PRs that actually fix those problems.

> Every time I try to clean up technical debt, a cadre arises objecting that it breaks existing code.

Yet I find dlangui to be broken at least once a month with every new DMD/Phobos release.

On Wednesday, 21 December 2022 at 19:35:54 UTC, Steven Schveighoffer wrote:
> Stop trying to fix C. Fix D instead.

> -Steve

Fully agree.

This thing right here https://dlang.org/spec/hash-map.html#static_initialization has been "Not YET implemented" for as long as I work with D (that's more than 3 years), and it doesn't seem to be bothering anyone. But yes, implementing a compiler inside a compiler is much more important, when the original compiler doesn't even work properly.

On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright wrote:
> On 12/21/2022 11:38 AM, Don Allen wrote:
> ImportC already has a couple extensions from D to make programming in it easier.
>
> But to address your point, ImportC has been a big success for D. People trying to interface D with C and C++ have many times

At last Beerconf I’ve made a poll for Jitsy users about tools for C interaction. ImportC got 0 votes…
the winner btw “manual export(C)” with 3 votes.
Of course the statistic is not representative, but still.

> lamented the lack of dynamic arrays in C and C++, leading to ugly interface hacks.
>
> The advantages are:
>
> 1. drawing attention to ImportC, which will draw attention to D

I really hardly imagine a solid C developer (like the level of OpenBSD hacker or Linux/Git kernel) who will use ImportC to have this feature, instead  of using gcc/clang/specific compiler for target(intel,nvidia,etc)

> 2. D can call ImportC code, and ImportC code can call D code.
> This will make one of the most-used features of D easy to cross over between the two languages.

There is no code with this syntax. D needs that ImportC will flawlessly work with current libraries and code, not with “code from future with improved features of C45”

> 3. Help get [..] into the C Standard which will help D, too, by making D easier to interface with C

How it helps to get it into C Standard? Isn’t it better to prepare PR for GCC and send DIP(or how they call it) to C Core community? And after it will be approved and widely used - add it to ImportC..

> 4. Getting it into C means better C debugger support for D

Same as above. Maybe use principles of KISS and Unix-way? For debugging use specific debugger-tools? Not “other language Interoperability tool”?

On Wednesday, 21 December 2022 at 19:59:58 UTC, Walter Bright wrote:
> On 12/21/2022 11:38 AM, Don Allen wrote:
>> Perhaps I'm missing something here. If so, please enlighten me.
>
> ImportC already has a couple extensions from D to make programming in it easier.
>
Which no one will ever use. :-)

On Wednesday, 21 December 2022 at 19:31:22 UTC, Walter Bright wrote:
>
> I posted this on Hacker News in response to an article about Microsoft's Checked C.
> =======================
> Checked C:
>
>     int a[5] = { 0, 1, 2, 3, 4};
>     _Array_ptr<int> p : count(5) = a;  // p points to 5 elements.
>
> My proposal for C:
>
>     int a[5] = { 0, 1, 2, 3, 4};
>     int p[..] = a;  // p points to 5 elements.
>
> https://www.digitalmars.com/articles/C-biggest-mistake.html
>
> https://github.com/Microsoft/checkedc/wiki/New-pointer-and-a...

I don't like Microsoft's Checked C.

I don't like your alternative. Not because it's not better than Microsofts, which yours certainly is, but because I don't believe C needs fixing.

I also don't want to have to learn new things, to program in C.
I'm sick of having to learn new things all the time!!
That's precisely why I like C. Cause I don't need to.
Sure C is unsafe, but that's the way I like it.

Having said that, I'd much rather see your alternative in the C standard, than Microsofts.

But I rather see neither.

The ship has sailed on C. Anyone that uses it knows it quirks and just deals with it.

Thankfully, it's extremely unlikely either would ever get into the standard in any case.

As for importC, I don't see a problem, since D should be able to provide extensions to it's C implementation, just as other implementators are free to do so.

On Thursday, 22 December 2022 at 10:44:07 UTC, areYouSureAboutThat wrote:
>

and just a followup to my previous post...

I'd like to see C modules in the standard, that's for sure.

Not this bounds checking nonsense!

Can you focus on C modules getting into the standard instead perhaps ;-)

On Thursday, 22 December 2022 at 07:59:58 UTC, Walter Bright wrote:
> On 12/21/2022 9:02 PM, H. S. Teoh wrote:
>> That's what versioning is supposed to solve.
>
> I know about versioning. But our -preview and -revert switches are better, as they allow the user to selectively decide which obsolete features they need.

Can you provide any example of successfully using these switches for anything practical other than just testing the compiler itself?

One practical scenario is bisecting several years of some application's commit history. But just having a battery of multiple old versions of DMD installed and using the appropriate compiler version to compile the code seems to be much more reliable and straightforward than fooling with the -revert switches.

Another practical scenario is having two libraries A and B as dependencies, where the former is super-modern and the latter is super-old and none of the DMD versions can successfully compile them both with default settings. Would -revert be really useful here? I don't know, this feels like a bad idea to me.

> The request is always "I want X bug fixed, I want to keep the old Y feature, I want the new Z feature."

What's wrong with such request? Assuming that the new feature Z doesn't break compatibility.

> But the people objecting to breaking code also object to using a -revert switch.

Again, is this -revert switch really useful for anything?

> Versioning comes with other problems. The most significant is we lack sufficient staff to maintain multiple versions.

If you spin it this way, then you also lack sufficient staff even to maintain just one most recent compiler version. Many bugs are rotting in bugzilla for years. But this isn't a good reason to give up and do nothing.

Would selecting some compiler version as LTS and backporting only minor bugfixes to it require too much effort? And if some fix is too difficult to backport, then the bug description and possible workarounds can be at least documented in some kind of errata list.

>> Freeze the current
>> language as version 2, put it on long-term maintenance, and start a new
>> branch as a new version with breaking changes that fix technical debts.
>
> The trouble there is that fixing bugs *also* comes with breaking existing code. There is no clean separation between the two.

Not every bugfix comes with breaking existing code.

And there's a big difference between breaking the existing *buggy* code (the maintainers of such existing code will be grateful for getting the bug exposed) and breaking some perfectly *valid* existing code due to unnecessary language syntax changes (the maintainers of such existing code will be only annoyed).

On 12/22/22 3:26 AM, GrimMaple wrote:

> This thing right here https://dlang.org/spec/hash-map.html#static_initialization has been "Not YET implemented" for as long as I work with D (that's more than 3 years), and it doesn't seem to be bothering anyone. But yes, implementing a compiler inside a compiler is much more important, when the original compiler doesn't even work properly.

I have a (clunky) library solution:

https://github.com/schveiguy/newaa

You can build one of those at compile-time, and use it at runtime, and it can be explicitly converted to/from builtin AA (without any copying), because it's binary compatible.

e.g.

```d
import std.stdio;
import schlib.newaa;

Hash!(string, int) aa = ["hello": 1, "world": 2];

void foo(int[string] x)
{
    x["blah"] = 5;
}

void main()
{
    foo(aa.asAA);
    writeln(aa["blah"]); // 5
}
```

-Steve

On Thursday, 22 December 2022 at 07:59:58 UTC, Walter Bright wrote:
> On 12/21/2022 9:02 PM, H. S. Teoh wrote:
>> That's what versioning is supposed to solve.

>
> Versioning comes with other problems. The most significant is we lack sufficient staff to maintain multiple versions.
>

Not enough development horsepower? All the more reason to do First Things First. I think much of this discussion is rooted in disagreement about what the First Things are.

On 12/22/22 00:59, Per Nordlöw wrote:
> 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?
>
> Good idea. I presume you're already keen on doing it so do it.

It's not clear how much sincere you were writing that but I agree: Life is too short to always do what needs to be done. I think people should be given liberty to do (or prioritize) what they want at least to increase motivation, creativity, serendipity, and more.

Ali