[cfe-dev] Criteria for Accepting Language Extensions into Clang

[George Russell]

Hi,

I have implemented a small language extension to C++, which motivates my 
interest in Clang + language extensions 
(https://bitbucket.org/grrussel/constcpp/wiki/Home) - which I would like 
to make available to a wider user base (if there is, in fact, interest 
in it) without being required to myself replicate the Clang / LLVM 
projects packaging work.

On 21/07/2011 19:40, Douglas Gregor wrote:
> Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria:
>
I wonder if there is any potential for what I have seen in LLVM - e.g. 
back-ends that are marked as unsupported, experimental; or of features / 
extensions being dropped if there is not an active maintainer. In other 
words, does inclusion necessarily require the unambiguous commitment to 
future support? Is there any potential for features explicitly marked as 
experimental and with the potential for future changes (including loss 
of backwards compatibility) and which could, at the discretion of core 
developers, simply be dropped between releases?

> 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users.

One motivation for getting an extension into Clang / LLVM is the ability 
to attract a larger community of users - it would be very easy to say, 
if you want to try "language extension X" it is available in some given 
Clang release for the range of platforms and targets it supports, as 
opposed to saying a) build it yourself, to a potential user or b) 
building + distributing the equivalent to a Clang / LLVM release yourself.

> 2) A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project.
>
In my case, I didn't see an existing mechanism to plug in the changes I 
wanted to make, short of directly changing the code. The changes are 
however, quite small; a pair of pragmas, a new language option, some 
additional changes in Sema etc executed only if enabled explicitly on 
the command line or via a pragma.

> 4) 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.
Is there any potential for an extension that is not intended to become a 
feature of language X version current + 1? I am aware of several 
extensions to various languages not intended to be such.
> 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler.
>
Yes; I would not argue that my extension is of such a quality, being at 
present a proof of concept; Is there scope for an incremental process 
where implemented extensions that the implementer desires to be merged 
could be reviewed, to allow feedback from the core developers of Clang 
etc to increase the quality of the implementation?

Regards,
George Russell