sob., 21 lut 2026 o 10:03 Jonathan Wakely <cxx_at_[hidden]> napisał(a):
>
>
>
> On Fri, 20 Feb 2026, 18:39 Marcin Jaczewski via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>>
>> Paper suggests rewriting `ptr->meber` by `(*ptr).member`.
>>
>> But this creates an interesting case, new `->` created this way will
>> have capabilities impossible compared to manually written `->`.
>>
>> Consider example:
>> ```
>> const auto& foo = ptr->member;
>> ```
>> and `ptr` that has a `*` returning proxy value.
>
>
> Is it common to return a proxy where you directly access its data member?
>
> I can't think of a case where I'd want that, rather than having a proxy where you use its member functions. But maybe I'm not imaginative enough.
>
>

Yes, this could be a corner case but lack of value categories for
`operator->` I would consider a bigger problem.

>
>> With this rewrite, the lifetime of the proxy object will be expanded
>> to the lifetime of the `foo` reference.
>> Using user defined `->` you can't in anyway do this as this operator
>> is required to return pointer and not value (as it will call nested of `->`).
>>
>> This is expected behavior? If yes then maybe we should
>> discourage of further use of user defined `->` operator?
>
>
> As I noted in another reply in the thread, you would probably still want operator-> for std::to_address to work on an end iterator, which is a requirement for iterators that model std::contiguous_iterator.
>
> If the paper gets approved, I would want compilers to warn about a contiguous iterator that doesn't define operator->.
>

If iterator is not owning then it probably should have user defined
`operator->` (as value categories and constness of iterator do not
matter), but on other hand it would not be UB, more compilation
failure as AFAIK explicit `x.operator->()` will not be rewritten and
will break compilation if someone try use it.