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