Am Dienstag, dem 28.04.2026 um 15:05 +0200 schrieb Martin Uecker:
> 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.

Sorry: "does not"

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