Just because I apparently was not very clear: in the "history" and "summarized objections" sections of my original mail, I did attempt to capture all of the objections from this thread and previous discussions I found (and, just for the sake of thoroughness, I do actually explicitly cite this thread in the footnotes). If you don't want to dig through the thread yourself, I hope that this will give you a good approximation of what happened in that thread.
I see now that I did fail to mention that this thread ended in nonconsensus rather than an explicit decision against. Sorry about that. You can also see evidence that the decision was nonconsensus directly in the JIRA issues and the review I cite -- for example on JIRA, Alex R mentions removing the newbie tag from the issue because there is nonconsensus, and the review was discarded, with the cited reason being nonconsensus. Hopefully this clarifies these issues. On Thu, Nov 5, 2015 at 8:32 AM, Alexander Rojas <alexan...@mesosphere.io> wrote: > While I’m all in on the proposal, we did have this discussion almost a year > ago [1] at the end I think, the decision was not to use them, though I don’t > remember the exact reason. In any case, I vote +1 non-binding. > > [1] > http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E > > <http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E> > > >> On 05 Nov 2015, at 06:36, Alex Clemmer <clemmer.alexan...@gmail.com> wrote: >> >> Hey folks. >> >> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh) >> brought up the issue of moving away from #include guards and towards >> `#pragma once`. >> >> As this has been brought up before, I will be brief: we think it's >> revisiting because the primary objection in previous threads appears >> to be that, though `#pragma once` is a cleaner solution to the >> multiple-include problem, it's not so much better that it's worth the >> code churn. However, the ongoing Windows integration work means we >> have to touch these files anyway, so if we agree this is cleaner and >> desirable, then this is an opportunity to obtain that additional code >> clarity, without the cost of the churn. >> >> For the remainder of the email, I will summarize the history of our >> discussion of this issue, who will do the work, and what the next >> steps are. >> >> PROPOSAL: We propose that all new code use `#pragma once` instead of >> #include guards; for existing files, we propose that you change >> #include guards when you touch them. >> >> HISTORY: This has been discussed before, most recently a year ago on >> the mailing list[2]. There is a relevant JIRA[3] and discarded >> review[4] that changes style guide's recommendation on the matter. >> >> SUMMARIZED OBJECTIONS: >> 1. The Google style guide explicitly forbids `#pragma once`. >> 2. This results in a lot of code churn, but is only marginally better. >> 3. It's not C++ standardized/it's platform dependent/IBM's compiler >> doesn't support it. >> 4. Popular projects like Chrome don't do `#pragma once` because of >> history clutter. >> 5. Intermediate state of inconsistency as we transition to `#pragma >> once` from #include guards. >> >> OUR RESPONSE: >> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon >> points out in a previous thread that the Google style guide was >> canonized when `#pragma once` was Windows-only, and the guidance has >> not changed since because of the history churn problem. As noted >> above, we think the history churn problem is minimized by the fact >> that it can be wrapped up into the Windows integration work. >> >> For objection (3), the consensus seems to be that the vast majority of >> compilers we care about (in particular, the ones supporting C++ 11) do >> support it. >> >> For objection (5) we believe the inconsistent state is likely to not >> be long lived, as long as we commit to wrapping this work up into the >> Windows integration work. >> >> SUMMARIZED ADVANTAGES: >> * Basically fool-proof. Communicates simply what its function is (you >> include this file once). Semantically it is "the right tool for the >> job". >> * No need for namespacing conventions for #include guards. >> * No conflicts with reserved identifiers[5]. >> * No internal conflicts between include guards in Stout, Process >> library, and Mesos (this is one reason we need the namespacing >> conventions) >> * Reduces preprocessor definition clutter (we should rely on #define >> as little as humanly possible). >> * Optimized to be easy to read and reason about. >> >> NEXT STEPS: >> If we agree that this is the right thing to do, committers would ask >> people to use `#pragma once` for new code when presented in code >> reviews. For files that exist, I will take point on transitioning as >> we complete the Windows integration work. I expect this work to >> completely land before the new year. >> >> >> Thanks, >> >> >> [1] https://reviews.apache.org/r/39803/ >> [2] https://www.marc.info/?t=142540100400015&r=1&w=2 >> [3] https://issues.apache.org/jira/browse/MESOS-2211 >> [4] https://reviews.apache.org/r/30100/ >> [5] >> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier >> >> >> -- >> Alex >> >> Theory is the first term in the Taylor series of practice. -- Thomas M >> Cover (1992) > -- Alex Theory is the first term in the Taylor series of practice. -- Thomas M Cover (1992)
