RFC: proposing to relax standardization requirements for Clang extensions

Tue Dec 7 14:00:20 PST 2021

On Tue, Dec 7, 2021 at 4:48 PM Arthur O'Dwyer <arthur.j.odwyer at gmail.com> wrote:
>
> 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. ;)

Thanks! And yeah, as a member on multiple standards committees, I
recognize it's a bit funny for this RFC to come from *me*. :-D

> 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.

Fair! FWIW, I don't know the intent of the original sentence, but I
know what I wanted it to mean.

> 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. ;)

I think we're in somewhat close alignment there. What I intend that
sentence to mean is that when Clang and the standard disagree on an
extension that's been standardized, the standard "wins" for the
standard spelling of the feature. e.g., we proposed _ExtInt to WG14
and the committee changed the type name to _BitInt, so it would be
Very Bad for Clang to then only expose _ExtInt and not _BitInt. My
intent was not "Clang should only implement what the standard
specifies because otherwise it's diverging."

~Aaron

>
> –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