Am Dienstag, dem 28.04.2026 um 13:11 +0200 schrieb Jens Maurer via Liaison:
>
> On 4/28/26 12:45, Aaron Ballman via Liaison wrote:
> > On Mon, Apr 27, 2026 at 3:51 PM Martin Uecker via Liaison
> > <liaison_at_[hidden]> wrote:
> > >
> > >
> > >
> > > Hi,
> > >
> > > n3876.pdf has the following example:
> > >
> > >
> > > template <typename Ty>
> > > void func(Ty *ptr, Ty val);
> > >
> > > _Optional int *ptr = foo();
> > > func(ptr, 12);
> > >
> > >
> > > as an example why the qualifier is at the "wrong" position
> > > and this would cause problems for C++. It states
> > >
> > > "When the qualifier is correctly associated with the pointer
> > > rather than the pointee, the semantics work as a C++ programmer
> > > would expect and Ty would deduce unambiguously to int"
> > >
> > > But if you replace "_Optional" with "const" the example also fails
> > > deduce unambigously. So is "const" also in the wrong location?
> > >
> > > Can somebody explain me what the authors mean?
> >
> > Ah, I can see how this wasn't worded clearly; "correctly associated"
> > was meant to imply changes to the code. But what we were trying to say
> > was: By applying the qualifier effects on the pointer despite being
> > written on the pointee, you create problems for type generic code like
> > that because it's an ambiguous deduction depending on the qualifier.
> > e.g., calling with _Optional int * and calling with const int * will
> > deduce differently under the proposed model were it to be supported in
> > C++ and we think they should deduce the same way (and be ambiguous in
> > that code example). We think users should write this instead:
> >
> > template <typename Ty>
> > void func(Ty *ptr, Ty val);
> >
> > int * _Optional ptr = foo();
> > func(ptr, 12);
> >
> > so that `Ty` deduces to `int` unambiguously, same as would happen with
> > `const` in that qualifier position.

Sorry, I still do not undertand this. We also put "const" on the
pointer target in function interfaces. The qualifier on the argument
itself does become part of the type of the function.

So are you saying "const" also causes problems for type generic code
and qualifiers are generally a problem in C++?

>
> Agreed; it's the pointer value that has a property (can it be null),
> not the pointee.

This is not how qualifiers work in C. They control the access rules
to an object and do not describe a property of the object itself.

This is also why they are dropped during lvalue conversion and do
become part of the function type, both would make no sense if they
described properties of an object instead of an access to an object.
 
Martin

>
> Jens
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2026/04/1632.php