Re: RFC: proposing to relax standardization requirements for Clang extensions
On Wed, Dec 8, 2021 at 3:48 PM Richard Smith wrote: > > On Tue, 7 Dec 2021 at 13:22, Aaron Ballman via cfe-commits > 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.) > > > VLAs in C++, [[]] in C, and enums with a fixed underlying type are all > instances of accepting a feature from one language mode in another. For those > cases, we do have a relevant standard on which to base our behaviour, so I > think those meet the current policy. I am less convinced of that, but understand where you're coming from. VLAs in C++ are a great example -- the C standard says what VLAs mean, but that doesn't cover very important topics like what happens with a VLA in a constant expression in C++. And the presence of our extension in this space can constrain WG21 from making future changes in the area because of fear of breaking our users of the extension. > Nullability qualifiers are part of the Mac OS language platform's SDK. In > this instance, Apple as a platform vendor decided to add an extension, and we > as vendors of a compiler that intends to support that platform, implement > that extension. I don't think this is all that different from our supporting, > say, to support intel platforms. Or our supporting MS > extensions to support the MS platform. And yet, they impact standardization nonetheless. There was a recent RFC about nonnull attributes that someone wishes to propose to WG14 and the nullability attributes were a part of that discussion. If a platform vendor needs to add an extension and that extension is sufficiently general enough to be standardized, I read the existing documentation as requiring them to bring it to a standards body. (Also, it seems to me that platform vendors are the one entity in the community that generally has the resources necessary for successful standardization -- it strikes me as odd to make it easier to exempt them from a requirement here.) That said, I definitely take your point that there are extensions vendors need to add for platform support which are not appropriate for standardization. (e.g., adding new intrinsics to support the platform, hooks required by the platform, attributes, etc.) > For _ExtInt, I specifically asked that this be proposed to WG14, and it was > (https://reviews.llvm.org/D59105#1422089). > > So, I think we may be missing some detail from the policy: > -- sometimes the relevant organization may be the owner of a platform or > architecture we care about supporting, rather than a language +1 > -- features supported for one language mode or platform are allowed to be > supported in other configurations too; if we're paying the cost of supporting > a feature, we should get as much benefit from it as we can I agree with this up to a point. I definitely agree we want to stretch our value where we can, but I would argue that support in one language mode is insufficient for automatic inclusion as an extension in another language mode unless it has a written specification for the behavior in that other language mode. For example, we don't document VLA support in C++ in any meaningful way (https://clang.
Re: RFC: proposing to relax standardization requirements for Clang extensions
On Tue, 7 Dec 2021 at 13:22, Aaron Ballman via cfe-commits < cfe-commits@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.) > VLAs in C++, [[]] in C, and enums with a fixed underlying type are all instances of accepting a feature from one language mode in another. For those cases, we do have a relevant standard on which to base our behaviour, so I think those meet the current policy. Nullability qualifiers are part of the Mac OS language platform's SDK. In this instance, Apple as a platform vendor decided to add an extension, and we as vendors of a compiler that intends to support that platform, implement that extension. I don't think this is all that different from our supporting, say, to support intel platforms. Or our supporting MS extensions to support the MS platform. For _ExtInt, I specifically asked that this be proposed to WG14, and it was (https://reviews.llvm.org/D59105#1422089). So, I think we may be missing some detail from the policy: -- sometimes the relevant organization may be the owner of a platform or architecture we care about supporting, rather than a language -- features supported for one language mode or platform are allowed to be supported in other configurations too; if we're paying the cost of supporting a feature, we should get as much benefit from it as we can > 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: > > - 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. > + 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. > + > > (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 t
Re: RFC: proposing to relax standardization requirements for Clang extensions
On Tue, Dec 7, 2021 at 4:48 PM Arthur O'Dwyer 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 > 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: >> >> - 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
Re: RFC: proposing to relax standardization requirements for Clang extensions
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@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: > > - 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. > + 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 ex
