[cfe-dev] RFC: proposing to relax standardization requirements for Clang extensions

[Aaron Ballman via cfe-dev]

tl;dr: our Clang "get involved" page implies that proposed extensions
to Clang must also be proposed to a standards committee
(https://clang.llvm.org/get_involved.html#criteria). This is a good
goal, but is not inclusive or something we enforce with any
consistency. I'm proposing to clarify our goals in this space and to
better reflect existing practice.

Inclusivity Issues:
Participating in a standards body is not always free. In fact, it can
be quite expensive depending on where you live and which committee you
want to join. People who wish to join the C or C++ standards committee
as a US national body member have yearly dues in excess of $2000/yr.
Each national body sets their membership fees individually and the
prices range anywhere from free to $7500+/yr. Also, a standards
proposal is not a "one and done" activity and often takes multiple
meetings to see even a trivial proposal adopted, but may require
multiple years for larger proposals. For example, the [[]] attributes
proposal took three years, and _BitInt took over two years with
multiple senior-level engineers working on it. Further, there are
associated travel costs (in non-pandemic times, anyway) with attending
meetings. This is a very significant financial and time burden that I
don't think we should require community members to take on.

Consistency Issues:
We have never been consistent at enforcing this requirement. Here are
some examples off the top of my head:

* Nullability qualifiers -- never proposed to WG14
* VLAs in C++ -- never proposed to WG21
* [[]] attributes in C -- proposed to WG14, accepted
* _ExtInt -- proposed to WG14, accepted as _BitInt
* enums with a fixed underlying type in C -- proposed to WG14 (not by
a Clang community member), still not accepted yet
* (This list is not intended to be exhaustive.)

Coupled with the time and monetary costs associated with
standardization, inconsistently applying something we say "must"
happen in our documentation is ripe for potential abuse (both
malicious and unintentional).

To this end, I'm proposing a change along the lines of:

-  <li>Representation within the appropriate governing organization: For
-  extensions to a language governed by a standards committee (C, C++, OpenCL),
-  the extension itself must have an active proposal and proponent within that
-  committee and have a reasonable chance of acceptance. Clang should drive the
-  standard, not diverge from it. This criterion does not apply to all
-  extensions, since some extensions fall outside of the realm of the standards
-  bodies.</li>
+  <li>Plausibility of standardization where applicable: Extensions with an
+  active proposal within a standards committee (C, C++, OpenCL, etc.) are
+  preferred when appropriate. Proposed Clang-specific extensions that are being
+  considered by a standards committee must have a feedback loop between the
+  community and the committee. Clang should drive the standard, not diverge
+  from it, so proposals currently in a standardization pipeline should not be
+  treated as finalized features in Clang until the standardization process has
+  completed and review can be done against the standard defining the feature.
+  Regardless of whether an extension is proposed for standardization, it must
+  be a conforming extension and it should not knowingly impede future
+  standardization efforts.
+  </li>

(I'll post an actual review for the changes, but I wanted folks to see
what I was going for as part of the RFC.)

The goal of the change is to make the following clear:

* We /prefer/ extensions to go through a standards body whenever possible
* We require extensions to be conforming and not knowingly impede
future standardization efforts
* Not all extensions are appropriate for standardization and that's fine
* If an extension is proposed to a standards committee, we expect the
community to have an active feedback loop with the committee
* Once a feature has been standardized, we expect Clang to expose the
standardized feature in a conforming way

I am wondering if others in the community feel we should make
adjustments along these lines to our getting involved page?

Thanks!

~Aaron