by aw1621107 | 2025-10-25 12:32:28+00:00
> Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong.

Turns out you have more than once. I wish I didn't have to spell this out for you, but here goes one last attempt...

The original part of awesome_dude's comment that started this subthread:

> Rust still has a very "Ready to make breaking changes on a whim" reputation

Note the existence and wording of the qualifier here. The claim here is not "Ready to make breaking changes", but "Ready to make breaking changes on a whim".

The relevant response from umanwizard:

> What breaking changes has Rust made "on a whim"?

Again, note the existence and wording of the qualifier. The question here is not "What breaking changes has Rust made", but "What breaking changes has Rust made 'on a whim'

Your first response:

> I don't know about "on a whim", but this isn't far off in regards to breaking compatibility.

This is the first goalpost move. You're not claiming to have an example of a breaking change "on a whim" (in fact, you explicitly distance yourself from such a claim), but instead you say you have an example of a breaking change that "isn't far off" of being "on a whim". Note that this is not the same unadorned "on a whim" qualifier, as it uses the (slightly) weakening and more vague "isn't far off". How far off and in what way is it not far off? You fail to elaborate on both counts.

Your next response:

> Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim.

A second goalpost move. You're not using the "isn't far off" qualifier any more, and are instead using the unadorned "on a whim". Again, you fail to elaborate further on this.

And finally:

> closer to "on a whim" than many like

A third goalpost move, with "on a whim" having grown two qualifiers, neither of which have previously appeared in this subthread! Now it's neither "on a whim" nor "isn't far off" "on a whim", but it's now "closer to" "on a whim" "than many like".

How close is "closer to"? Who falls under "many"? How do these describe the example you provide? Who knows!

> And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation.

It's not clear to me why it's so hard to understand what this subthread was originally about, nor why you seem so insistent on refusing to actually discuss the original topic.

> Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility.

This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem".

> The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled.

Not only does this claim contradict the snippets I quoted earlier, it also contradicts this other snippet from the docs (emphasis added) [0]:

> On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard.

And given that GCC defaults to said GNU dialects, that means that non-strict-superset features are enabled by default.

[0]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html