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.
> Again, the fact that Rust can and will break backwards compatibility is not in dispute. It's specifically the claim that it's done "on a whim" that was the seed of this subthread.
And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation.
> No need for a thought experiment. Straight from the GCC docs [0]:
Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. A program written in pure C or C++ ought to behave exactly the same and compile exactly the same as in those default dialects. 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.
Thus, yet again, radically different from what the rustc developers did just last year.
Overall, your posts and the posts of your fellow Rust proponents in this submission both worsen the situation for Rust and for software overall regarding compatibility, security and safety, as the bug of the submission indicates. Imagine being so brazen and doubling down on a path that arguably lead to a very public bug. I do not believe any responsible software company would want you anywhere near its code if it cared about safety and security.
> 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.
> 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".
Do you consider old program now compiles, that previously didn't to be a serious break in backward compatibility? I think they do not, and so do I.
If I'm understanding you correctly, I don't, but I interpreted the GCC docs to indicate the opposite. To me, the docs indicate that it's possible (albeit unlikely) for a program that compiles under -std=c* to fail to compile under -std=gnu* due to one of those extensions that "conflict with the [C/C++] standard" and/or "change the meaning of the base standard".
> To me, the docs indicate that it's possible (albeit unlikely) for a program that compiles under -std=c* to fail to compile under -std=gnu* due to one of those extensions that "conflict with the [C/C++] standard" and/or "change the meaning of the base standard".
That's correct. There are not much of those, but they do exist. These generally mean that the GNU dialect gave syntax a meaning, back when it was still forbidden in standard C. Then standard C adopted that feature due to it being implemented in a compiler (that's how language evolution should work), but gave it slightly different semantics. Now GCC has the choice between breaking old existing programs, or not exposing standard semantics by default. They solve that by letting the user choose the language version.
An example of that are arrays of size 0 at the end of a structure. This used to be used for specifying arrays whose size can be arbitrary large, but became obsolete with the introduction of flexible array members in C99. Now if GCC would only implement standard C, then the correct semantics for any array with a declared size that is accessed with an index larger than that size, would be undefined behaviour, but since GCC gave that the semantics, that now flexible array members have, before flexible array members existed, it chooses to implement these semantics instead, unless you tell it, which C standard you want to use.
Actually due to the use in popular codebases, such as the Linux kernel, this semantic is even assigned (based on a heuristic) with array sizes larger than zero.
> In the absence of the zero-length array extension, in ISO C90 the contents array in the example above would typically be declared to have a single element. Unlike a zero-length array which only contributes to the size of the enclosing structure for the purposes of alignment, a one-element array always occupies at least as much space as a single object of the type. Although using one-element arrays this way is discouraged, GCC handles accesses to trailing one-element array members analogously to zero-length arrays.
(With GNU projects when you have questions, the best source are the official docs themself. They are stellar and are even completely available offline on your computer in the interactive documentation system Info.)
I did take a quick glance through some of the extension docs, but it seems the particular subsection you discuss was not among the pages I happened to look at. I had never had occasion to use the GNU dialect in the past and searches weren't helping me find specific examples, so I appreciate you taking the time to elaborate!
Out of curiosity, which pages did you discover? Not as in "You hold it wrong.", but as in "Which pages does the unfamiliar discover.".
Are you on an OS, where using the GNU Info system is an option? I quite like it. Unfamiliar people often are deterred from using it, either, because it is in the terminal, or, because they think they are looking at a pager. When it's only the latter preventing you from using it, have in mind, that this is not in fact a simple paged document, but an interactive hypertext system, that predates the WWW. Documents are generally structured as a tree. Use the normal cursor movement, use Enter to follow links, p for previous node, n for next node, u / backspace for up/parent node, / works for text search, i searches in the index. Use info info when you want to know more. Pressing h for help also works. (I just discovered that the behaviour of h depends on your terminal size :-) .) When you look at the GNU onlinedocs, you look at a HTML version of that Info document. Using Info directly is nicer, since it has native support for jumping in the doc tree and instead of relying on an external entity (like Google) to point you to the node that contains your information (Often resulting in bringing you at another version or document entirely, which can lead to confusion.) you can use the built-in index, which is maintained by the document authors, so it will be accurate.
GNU Info is in my opinion the best and fastest way to access documentation, that is more then a simple reference sheet, when you don't object to leaving the Web browser. It even has C tutorials and all, completely offline.
IIRC I was basically doing a top-down search starting from the "Extensions to the C Language Family" [0] and the "Extensions to the C++ Language" [1] pages. I did come across the syntax/semantic extensions subpages you list, but I didn't comprehensively go through all the extensions.
> Are you on an OS, where using the GNU Info system is an option?
Technically yes, but I admittedly have basically zero experience with using it.
> Using Info directly is nicer, since it has native support for jumping in the doc tree and instead of relying on an external entity (like Google) to point you to the node that contains your information (Often resulting in bringing you at another version or document entirely, which can lead to confusion.) you can use the built-in index, which is maintained by the document authors, so it will be accurate.
I'm not entirely confident about how helpful it'd be for someone who is less familiar with the subject material like me as opposed to someone who has a general idea of what they're looking for, but I suppose I won't know until I try it.
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.
> Again, the fact that Rust can and will break backwards compatibility is not in dispute. It's specifically the claim that it's done "on a whim" that was the seed of this subthread.
And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation.
> No need for a thought experiment. Straight from the GCC docs [0]:
Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. A program written in pure C or C++ ought to behave exactly the same and compile exactly the same as in those default dialects. 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.
Thus, yet again, radically different from what the rustc developers did just last year.
Overall, your posts and the posts of your fellow Rust proponents in this submission both worsen the situation for Rust and for software overall regarding compatibility, security and safety, as the bug of the submission indicates. Imagine being so brazen and doubling down on a path that arguably lead to a very public bug. I do not believe any responsible software company would want you anywhere near its code if it cared about safety and security.