Fixing C's Biggest Mistake

[Siarhei Siamashka]

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