4 ms·

The two middle quotes come from the article. They illustrate that the authors are interested in removing aspects of the language that contribute to tooling comp

The two middle quotes come from the article. They illustrate that the authors are interested in removing aspects of the language that contribute to tooling complexity. The compilers that the authors care about are a small number of open source compilers that have very comprehensive support, and consequentially are very complex, probably just gcc and clang. With regard to this perspective, something like “lines of text in the standard” isn’t a useful metric. Few people are going to read the entire standard, so there’s little harm in making it longer, but many people are going to work on large compiler projects, and many, many people are going to use the compilers these projects produce. The standard can be made more complex in ways that reduce the required complexity of comprehensive optimizing compilers.

kazinator 6y ago
Numerous instances of wording in the article strongly suggest that the authors seem to be working under the confusion that ISO C++ is a compiler project, rather than a language specification. > The compilers that the authors care about are a small number of open source compilers If so, that is an unacceptable position for people on an ISO committee for that programming language.
- dodobirdlord 6y ago
  > Numerous instances of wording in the article strongly suggest that the authors seem to be working under the confusion that ISO C++ is a compiler project, rather than a language specification. There is no possibility that any of the authors are working under this confusion. The language specification heavily influences compiler projects because compiler authors tend to target standards. The argument that authors can just write their own non-standard compiler doesn't generally carry much water. Moreover it is extremely common for the standard to be written specifically to assist compiler authors. Consider the numerous instances of undefined or implementation defined behavior. > If so, that is an unacceptable position for people on an ISO committee for that programming language. The purpose of a standards committee is to standardize, not to standardize anything in particular. If the committee can be persuaded that these use cases are important to a large body of C++ programmers and that the alternative may be a split in the community, the committee may be inclined to adopt some of these topics as areas for improvement.
  - kazinator 6y ago
    > not to standardize anything in particular. Oh no, no. There is something particular to standardize: namely something that is already out there and working. Secondly, if there are multiple such somethings that are out there and working, but are not compatible, then this is where the standard is really in its own element, to help iron out that situation and improve interoperability. In this second area, the standard may engage in a bit of invention. Pure, unprompted invention is something ISO standards should eschew.

kazinator 6y ago

Numerous instances of wording in the article strongly suggest that the authors seem to be working under the confusion that ISO C++ is a compiler project, rather than a language specification. > The compilers that the authors care about are a small number of open source compilers If so, that is an unacceptable position for people on an ISO committee for that programming language.

dodobirdlord 6y ago
> Numerous instances of wording in the article strongly suggest that the authors seem to be working under the confusion that ISO C++ is a compiler project, rather than a language specification. There is no possibility that any of the authors are working under this confusion. The language specification heavily influences compiler projects because compiler authors tend to target standards. The argument that authors can just write their own non-standard compiler doesn't generally carry much water. Moreover it is extremely common for the standard to be written specifically to assist compiler authors. Consider the numerous instances of undefined or implementation defined behavior. > If so, that is an unacceptable position for people on an ISO committee for that programming language. The purpose of a standards committee is to standardize, not to standardize anything in particular. If the committee can be persuaded that these use cases are important to a large body of C++ programmers and that the alternative may be a split in the community, the committee may be inclined to adopt some of these topics as areas for improvement.
- kazinator 6y ago
  > not to standardize anything in particular. Oh no, no. There is something particular to standardize: namely something that is already out there and working. Secondly, if there are multiple such somethings that are out there and working, but are not compatible, then this is where the standard is really in its own element, to help iron out that situation and improve interoperability. In this second area, the standard may engage in a bit of invention. Pure, unprompted invention is something ISO standards should eschew.