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

[Arthur O'Dwyer via cfe-dev]

Hi Aaron,

FWIW, I like your new wording (and rationale for it) better than the old
wording. Of course I've got a conflict of interest, because of P1144
[[trivially_relocatable]] and P2266 "Simpler implicit move" and so on. ;)

This sentence in particular, though...
> Clang should drive the standard, not diverge from it

What was the intent of this sentence in the old version, and what is its
intent in the new version? It's very open to interpretation.

What I'd personally *like* it to mean is, "Clang should drive the standard:
We believe that WG14, WG21, and other standards bodies should *standardize
existing practice*. This means that compiler vendors have a responsibility
to pioneer that existing practice, off-loading some of the risk from the
language committees. We are willing — even eager — to support useful
extensions, knowing that our implementation experience will inform those
bodies' deliberations. We are willing — even eager — to support useful
extensions even though they may *never* be standardized. We are willing —
even eager — to support useful extensions even knowing that there is a risk
that something *different* may be standardized (in which case, we will
responsibly deprecate our extension in favor of the standard
implementation). We take seriously our responsibility to act as
trailblazers and testing grounds, and to lead the way for the more
conservative language committees."

But I don't know if that's what *you* think it means. ;)

–Arthur


On Tue, Dec 7, 2021 at 4:22 PM Aaron Ballman via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> 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
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211207/312d9119/attachment.html>