_Optional: a type qualifier to indicate pointer nullability

[Christopher Bazley <cs99cjb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

In August, I had an idea for a C language extension to improve null pointer
safety. The tl;dr is that whereas a pointer-to-const may have undefined
behaviour on write access, a pointer-to-_Optional may have undefined
behaviour on read or write access. I shared this proposal with my
colleagues, many of whom offered feedback and suggested improvements.

Having finished prototyping my idea in Clang and experimentally applying it
in a large closed-source codebase, I recently submitted a paper (n3089) to
the WG14 committee in charge of C standardisation for ISO:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3089.pdf

I also wrote an article explaining every aspect of my design and prototype:
https://medium.com/itnext/why-c-needs-a-new-type-qualifier-61ad553cbe71
(long! sorry)

I had hoped that a working prototype would help further my cause, but the
code owners for Clang have just rejected my patches:
https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/

Obviously, I am disappointed -- not only because of the huge amount of
thought and effort I put in, but also because I genuinely believe in the
potential of my idea to transform C programming for the better
(particularly when compared to the alternatives).

In my experience my prototype works better than Clang's existing solution
in the same problem space, yet its implementation is orders of magnitude
simpler. Some of the issues with Clang's nullability qualifiers are bugs;
others are more conceptual. I raised some of the issues I found in another
thread:
https://discourse.llvm.org/t/nullability-analyzer-doesnt-seem-to-work-and-how-to-fix-it/

Does the lack of support for Clang's nullability qualifiers in GCC indicate
a greater likelihood for my proposed feature to be accepted into GCC? I am
determined to avoid putting a huge amount of my own time into another
inplementation, only to have it rejected again.

If my proposal has little value to you (quite likely, if you are a C++
programmer), please bear in mind that it is just a simple tool (like
'const') that individuals can choose to use, or not. It entails only a
minor change to the semantics of one operator. Yes, it is contagious, but
nobody will be forced to use _Optional in their project, and it is easy to
hide using a macro. I don't feel that it deserves to be killed at birth.

Please could someone direct me to the process and/or gatekeepers
responsible for allowing such an extension into GCC.

Thanks for reading
-- 
Christopher Bazley
-- 
Christopher Bazley