_Optional: a type qualifier to indicate pointer nullability

_Optional: a type qualifier to indicate pointer nullability

[Christopher Bazley]

[-- 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

Re: _Optional: a type qualifier to indicate pointer nullability

[Jonathan Wakely]

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

On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
wrote:

>
> 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?


No, I don't think so. I think it would be better to support the same
qualifiers as Clang, not diverge in this way.

I agree with Aaron Ballman when he said:

"The proposal is largely experimental in terms of design and needs a
stronger indication that a standards body really believes in this design
(in terms of syntactic choices, at the very least) and data demonstrating
how this feature catches bugs that cannot be caught by other features in
the same space (not just due to missing diagnostics that are possible to
implement)."

In fact I agree with most of his comment at
https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004/16

I particularly agree that no new language extension is needed to express a
pointer that can be null, that's just how pointers have always worked. A
pointer that cannot be null is more deserving of special attributes or
qualifiers to say that it has additional guarantees that aren't implied by
just being a pointer.



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.
>

Language extensions don't deserve to be added to a compiler just because
somebody put a lot of work into them.



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

A thread like this on the mailing list is how such decisions get made.

Re: _Optional: a type qualifier to indicate pointer nullability

[Christopher Bazley]

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

On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

>
> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
> wrote:
>
>>
>> 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?
>
>
> No, I don't think so. I think it would be better to support the same
> qualifiers as Clang, not diverge in this way.
>

Clang’s _Nullable qualifier is broken and pretty useless (even according to
the code owner), so good luck with that.

In fact I agree with most of his comment at
>
> https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004/16
>
> I particularly agree that no new language extension is needed to express a
> pointer that can be null, that's just how pointers have always worked. A
> pointer that cannot be null is more deserving of special attributes or
> qualifiers to say that it has additional guarantees that aren't implied by
> just being a pointer.
>

It’s not a matter what which kind of pointer is “deserving”. One choice is
pleasant and expressive, whereas the other (C with _Nonnull attributes) is
neither type-safe nor ergonomic.

Meanwhile, on Reddit, my proposal has an 85% upvote rate, and on LinkedIn,
“Great idea and I hope it gets itself in to a future standard, but I
couldn't wait for something like that to arrive in C…”

I wonder how many other people “couldn’t wait”. I guess they already left
the debate.

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.
>>
>
> Language extensions don't deserve to be added to a compiler just because
> somebody put a lot of work into them.
>

I never said that they did. You’ve conflated two unrelated paragraphs.

-- 
Christopher Bazley

Re: _Optional: a type qualifier to indicate pointer nullability

[Jonathan Wakely]

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

On Sat, 4 Feb 2023, 21:23 Christopher Bazley, <cs99cjb@gmail.com> wrote:

>
>
> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
>
>>
>> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
>> wrote:
>>
>>>
>>> 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?
>>
>>
>> No, I don't think so. I think it would be better to support the same
>> qualifiers as Clang, not diverge in this way.
>>
>
> Clang’s _Nullable qualifier is broken and pretty useless (even according
> to the code owner), so good luck with that.
>

But marking pointer arguments as non-null is already supported in GCC (with
an attribute on the function, not the argument). Supporting a nonnull
attribute on individual arguments seems useful to me. Far more than marking
pointers as maybe-null, which is already true for all pointers.

Re: _Optional: a type qualifier to indicate pointer nullability

[Christopher Bazley]

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

On Sat, 4 Feb 2023 at 23:53, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

>
>
> On Sat, 4 Feb 2023, 21:23 Christopher Bazley, <cs99cjb@gmail.com> wrote:
>
>>
>>
>> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely <jwakely.gcc@gmail.com>
>> wrote:
>>
>>>
>>> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
>>> wrote:
>>>
>>>>
>>>> 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?
>>>
>>>
>>> No, I don't think so. I think it would be better to support the same
>>> qualifiers as Clang, not diverge in this way.
>>>
>>
>> Clang’s _Nullable qualifier is broken and pretty useless (even according
>> to the code owner), so good luck with that.
>>
>
> But marking pointer arguments as non-null is already supported in GCC
> (with an attribute on the function, not the argument). Supporting a nonnull
> attribute on individual arguments seems useful to me. Far more than marking
> pointers as maybe-null, which is already true for all pointers.
>

Sorry, but I get the feeling that you didn’t read my article. If you could
spare the time, it would help you to understand where I’m coming from.
Saying “it’s already true that all pointers can be null [therefore there’s
no need for ‘_Optional’ in the type system]” is as facile as saying “it’s
already true that all values in Python can be None”.

I’d sooner trust Guido van Rossum on this question than Bjarne Stroustrup,
since the former actually *likes* C and uses it, whereas the latter
describes C as a perverse mess (and certainly doesn’t use it).
-- 
Christopher Bazley

Re: _Optional: a type qualifier to indicate pointer nullability

[Jonathan Wakely]

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

On Sun, 5 Feb 2023, 08:07 Christopher Bazley, <cs99cjb@gmail.com> wrote:

>
>
> On Sat, 4 Feb 2023 at 23:53, Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
>
>>
>>
>> On Sat, 4 Feb 2023, 21:23 Christopher Bazley, <cs99cjb@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely <jwakely.gcc@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
>>>> wrote:
>>>>
>>>>>
>>>>> 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?
>>>>
>>>>
>>>> No, I don't think so. I think it would be better to support the same
>>>> qualifiers as Clang, not diverge in this way.
>>>>
>>>
>>> Clang’s _Nullable qualifier is broken and pretty useless (even according
>>> to the code owner), so good luck with that.
>>>
>>
>> But marking pointer arguments as non-null is already supported in GCC
>> (with an attribute on the function, not the argument). Supporting a nonnull
>> attribute on individual arguments seems useful to me. Far more than marking
>> pointers as maybe-null, which is already true for all pointers.
>>
>
> Sorry, but I get the feeling that you didn’t read my article. If you could
> spare the time, it would help you to understand where I’m coming from.
>

I read it. All. Even though it's very long. And the summary post. And I
skimmed the WG14 proposal when that was sent to WG14. And the LLVM
discourse thread. I just don't agree with your position on it.