[cfe-dev] RFC: Nullability qualifiers

David Blaikie dblaikie at gmail.com
Sun Mar 15 16:58:38 PDT 2015


On Mar 15, 2015 3:55 PM, "Adrian Sampson" <asampson at cs.washington.edu>
wrote:
>
> >> * 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.

Delesley - this is alls sounding a but familiar?

>
> Adrian Sampson
> University of Washington
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150315/68246b69/attachment.html>


More information about the cfe-dev mailing list