[cfe-dev] RFC: Nullability qualifiers
Adrian Sampson
asampson at cs.washington.edu
Sun Mar 15 15:24:17 PDT 2015
>> * Based on your discussion of type system impact, I'm sure you are all well aware that the compiler support for "maintaining type sugar through semantic analysis" needed to make this proposal work is *almost* enough to support a full "plug-able type system" similar to what's available in recent versions of Java. Do you have any plans to address the missing pieces? Being able to support pluggable type information more broadly (while continuing to guarantee that adding such qualifiers/attributes/however-it's-expressed would have zero impact on generated code) would enable all sorts of interesting analyses. A few examples that spring to mind include compile-time enforcement of physical unit compatibility, various protocol-level checks (type states, a la Bierhoff & Aldrich), and many more. When last I investigated this question (about a year ago), the limitation regarding templates (your [6]) was the only significant missing piece. Closing that gap would greatly reduce the difficulty (and project risk) of implementing such analyses.
>
> We’re almost there in Clang, although I doubt that I personally will have time any time soon to work on addressing the issue of type sugar flowing through template specializations. I don’t think it’s fundamentally that hard to do, and beyond that I expect that we’ll see a long tail of small issues where we’re not maintaining type sugar everywhere.
I’ve been working on a very hacky implementation of pluggable types for Clang. In fact, one of the prototypes I developed for the system is a simple nullability qualifier. There’s a little more detail on my blog:
http://homes.cs.washington.edu/~asampson/blog/quala.html
http://homes.cs.washington.edu/~asampson/blog/quala-codegen.html
So I’m very interested in generalizing mechanisms like what’s proposed here for __nonnull. This may be more straightforward to implement once __nonnull itself has landed. (At the very least, it should pave the way for my project’s patch to be smaller.) If anyone else is interested, let’s talk and perhaps put together a proposal.
Adrian Sampson
University of Washington
More information about the cfe-dev
mailing list