On Wednesday, 21 December 2022 at 19:09:37 UTC, Walter Bright wrote:
> I'm wondering. Should I just go ahead and implement [..] in ImportC?

I don't think it will be of much use. If I want to compile an existing C project, it won't have D slices. If I want to write new code, I presumably want to write standard C. If I'm willing to restrict myself to use a D compiler to compile my code, why in the world would I write C?

That said, the feature would not cause issues either since it doesn't need to be used. If it's already worth making for easing testing of other ImportC features, it probably doesn't hurt having it as a curiosity for users.

On Thu, Dec 22, 2022 at 03:23:50PM +0000, Don Allen via Digitalmars-d wrote:
> 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.

We've been in disagreement about what the First Things are for many years now, unfortunately. :'(


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

On 12/22/2022 4:05 AM, Siarhei Siamashka wrote:
>> 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.

Everyone has a different XYZ combination they want. This is why versioning does not work.


>> But the people objecting to breaking code also object to using a -revert switch.
> Again, is this -revert switch really useful for anything?

More useful than versions.


> Would selecting some compiler version as LTS and backporting only minor bugfixes to it require too much effort?

If someone wants to volunteer to do this, I would welcome it. In fact, an LTS version isn't even necessary. Any fix could be backported to any previous D release.


> Not every bugfix comes with breaking existing code.

I didn't say every. But a lot of critical bugs do.


> 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).

One person's valid code is another's bug. Fixing autodecoding, for example, breaks existing code.

On 12/22/2022 7:23 AM, Don Allen wrote:
> 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.

Of course. Everyone has a different view of what FT are. Trying to manage that is the most difficult job I have. There isn't any magic solution. Somebody is always going to be unhappy with the choice.

On Thursday, 22 December 2022 at 20:46:29 UTC, Walter Bright wrote:
> On 12/22/2022 7:23 AM, Don Allen wrote:
>> 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.
>
> Of course. Everyone has a different view of what FT are. Trying to manage that is the most difficult job I have. There isn't any magic solution. Somebody is always going to be unhappy with the choice.

It doesn't matter if *someone* is unhappy with the choice. What matters is if your choices, as the project leader, generally make sense to the troops. You don't need unanimity. You need majority support.

On 12/22/2022 7:51 AM, Ali Çehreli wrote:
> 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.

It's also a low effort / low risk job, like implementing bitfields in D after having developed and debugged them with ImportC.

On 12/22/2022 12:26 AM, GrimMaple wrote:
> Show me any project that successfuly uses ImportC, or didn't happen.

Phobos compiles its C files with ImportC.

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.

On 12/22/2022 2:48 AM, areYouSureAboutThat wrote:
> Can you focus on C modules getting into the standard instead perhaps ;-)

My attempts at getting things into the C or C++ standard have all failed.

That doesn't mean they haven't gotten into the standard. They've copied successful D features!

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?

I think it fits D better than C, to be fair. There was a DIP many years ago about implementing a way in the language to avoid using staticArray, I think that would fix the issue neatly.