Am Dienstag, dem 28.04.2026 um 18:43 +0200 schrieb Jens Maurer:
>
> On 4/28/26 15:56, Martin Uecker wrote:
> > > In Aaron's and my alternate world, we'd need a more nuanced brush for
> > > "dropping qualifiers" when forming the signature of a function in C.
> > >
> > > void f(int * const); === void f(int *);
> > >
> > > But maybe don't drop the _Optional here when forming the signature:
> > >
> > > void f(int * _Optional);
> >
> > But "not dropping the qualifier" would follow naturally when putting
> > it on the pointee. So this would seem to give you the right semantics
> > using existing language mechanisms when putting on the pointee. So now
> > I am even more confused about what the problem is.
>
> I guess part of the problem is how much of _Optional is part of the
> type system.

Whether one wants a type-system solution or not can certainly
be discussed.

But I actually didn't want to discuss the overall design, but
understand the C++-specific issue which the papers tries to point out.
I am still completely at loss regarding this point.

To me it seems that _Optional, as designed, would also do exactly
the right thing for templates.

>
> > But neither "const", "volatile" nor "_Optional" describe a
> > property of an object, they all describe semantics of an
> > access to an object using the giving type of the lvalue.
>
> > For "const" it says you can not write using that lvalue,
> > for "volatile" it says that all accesses appear according
> > to the rules of the abstract machine,
>
> Right. For these two cases, we first do *x
> and then ask whether it's allowed to modify via that lvalue
> and/or what accesses through *x mean in the abstract
> machine.
>
> > and for "_Optional"
> > it says that an access without prior null pointer check
> > is forbidden.
>
> And that seems qualitatively different to me: We (want to)
> diagnose the formation of *x (the lvalue) without a surrounding
> "if" guard, not the use of that lvalue afterwards.
>
> So, it's a restriction on stuff you can do with the pointer x,
> not on stuff you can do with the lvalue formed by *x.

We would want to diagnose the unprotected access and not
already the formation of *x. So in both cases we
restrict how the lvalue *x can be accessed while the pointer
value itself can be passed around without any restriction.

>
> (Lvalues are more prevalent in C++ than they probably
> are in C, so this probably is more of a pain point from a
> C++ viewpoint.)

But nobody so far could explain what the pain point actually is!

Martin


>
> Jens