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.

~Aaron