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.

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

Jens