Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Date: Tue, 31 Jan 2023 07:54:27 -0800 Organization: A noiseless patient Spider Lines: 42 Message-ID: <86o7qeem30.fsf@linuxsc.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="d7afdbadfc82629bf49e932b5bae181b"; logging-data="4076231"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ySF4oC5rq+0c8U/pro2Mzfqz/lufe8So=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:FgTv6zo5PHOnlv2x9vfImmqG3D4= sha1:EeyJEUhs13K+S01bydmu506XVBU= Xref: csiph.com comp.lang.c:169151 Christopher Bazley writes: > Hi all, > > I've just submitted my paper n3089, "_Optional: a type qualifier to > indicate pointer nullability" to the WG14 committee. [...] > > I wrote a Medium article with much the same content as my paper, > which is published here: > https://medium.com/itnext/why-c-needs-a-new-type-qualifier-61ad553cbe71 > > [...] I looked at the article on Medium and also n3089. I've read through most of the postings in the thread here, not necessarily thoroughly but sometimes only skimming. What you're proposing is fundamentally broken. There are two reasons for this: One, how the _Optional qualifier works is radically different from how other type qualifiers work. That by itself is enough to make the new feature a non-starter. Two, I'm not sure I follow what the rules are for how compilers have to treat _Optional pointers, but it seems one of two things is true. Either the new feature breaks a lot of existing code, or it doesn't affect the semantics of the program, in the sense that adding or taking away _Optional has no effect on whether the behavior is defined, or what the behavior is, or whether the program may be rejected. Breaking existing code is an absolute deal breaker. But the other alternative is useless, because there are no consequences; any warnings produced can be safely ignored, and that's what people will do, and compilers will have an option to suppress the warnings. These issues are not minor points that can be patched up. To be successful the question needs to be completely re-thought. By the way, regarding the written proposal (and article), considered separately from what is being proposed, I'm sorry to be blunt but it's awful. I'm thinking of writing a short essay about how to write these things but I haven't done that yet. Hopefully soon.