Not sure I entirely follow your train of thought about the smart pointers..
Are you suggesting that smart pointers should forward operator'.' to
whatever they are pointing to? Then how would we distinguish e.g. a
'pointer.reset()' from a potential 'pointer->reset()' if whatever it is
pointing to also happens to provide a method 'reset'? Or any other member
methods of a smart pointer. Similar arguments are made for optional,
expected...
If you are suggesting that smart pointers should keep their operator->()
then they are not so much pointers as more "pointer like" because they no
longer support the same API.
I also have a "hygience" argument that raw pointers should not be the
"go-to" when dealing with references (that would be, well, references) and
definitely not resource management. They should mainly be used when you
need to re-point a reference for various reasons, and in those situations I
second what has been said before: the different access syntax makes it
perfectly clear that something here might need to be checked before the
access, even when not viewing the code from an IDE.

My 2c.

// Robin

On Sun, Feb 2, 2025, 10:39 J Decker via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Sun, Feb 2, 2025 at 1:04 AM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>>
>>
>> On Sun, 2 Feb 2025, 07:00 J Decker via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> The most notable complaint is loss of information about the
>>> preceding variable's type.... which can be handled with variable name
>>> notation like 'pBlah' vs 'oBlah'...
>>>
>>
>> No, Hungarian notation is not an acceptable alternative.
>>
>> The second complaint is the conflict with smart pointers...
>>> I wasn't quick enough at the time to say 'well if you're pushing use of
>>> smart pointers, and
>>>
>>
>> What does "pushing use of smart pointers" mean? Sounds like opinionated
>> nonsense.
>>
>
> I feel like there's sections of the minutes missing; it was said something
> like 'we are suggesting use of smart points anyway' with pushing being my
> paraphrase for the same idea... it might have even been pushing; but
> there's only one instance of 'smart' in the minutes, and I'm certain that
> word was said more than once.
>
>
>>
>>
>> this doesn't affect smart pointers, since '.' already has a well defined
>>> behavior... it's a nothing-burger for you anyway; and would just be part of
>>> compatibility with C' (extending '.' to look at the left type).
>>>
>>
>> I'm not sure what you're trying to say. If -> is not used for pointers,
>> but is still used for smart pointers and std::optional etc then you haven't
>> really simplified anything. Just created inconsistency where there was
>> consistency before.
>>
>
> I understand this viewpoint; but in having accepted '.' (in a post '.'
> derefercing pointer view) it is a consistent behavior to access a member of
> an object rather than 2 methods. Just because idomatic C++ doesn't get the
> same benefit of 'consistency' now that you mention these things, seems
> unfair to keep others from having it... but then who besides me maintains C
> that is also C++ compilable? Do we/should we really even care about
> compatibility?
>
>
>>
>> The motivation for this change is very weak.
>>
>>
>>
>>> there is typically one extra memory lookup when following '.'.
>>>
>>> Legacy behavior can be enforced by a linter.... but I've been
>>> considering adding it as a modification to the existing error to indicate
>>> that another option may be used to enable this behavior - then at least
>>> it's an opt-in; though that's a bit more work to implement than just the
>>> few lines in the right places...
>>>
>>> Jim
>>>
>>> On Sat, Feb 1, 2025 at 3:53 AM Sebastian Wittmeier via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> Because it is an active thread, I want to mention that there has been
>>>> an update by SG22 (the C/C++ Liaison), now it is back in EWGI's court:
>>>>
>>>>
>>>>
>>>> "Seen by SG22. Feedback to the author given. We do not think this paper
>>>> is a good candidate for inclusion in C++. See minutes for details of
>>>> discussion."
>>>>
>>>> https://github.com/cplusplus/papers/issues/868
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> *Von:* Filip via Std-Proposals <std-proposals_at_[hidden]>
>>>> *Gesendet:* Fr 31.01.2025 11:33
>>>> *Betreff:* Re: [std-proposals] Possible deprecation of -> operator
>>>> *An:* std-proposals_at_[hidden];
>>>> *CC:* Filip <fph2137_at_[hidden]>;
>>>> Hi thanks for that link, I will try and help with this.
>>>>
>>>> Cheers, Filip
>>>>
>>>> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <
>>>> std-proposals_at_[hidden]> w dniu 31 sty 2025, o godz. 11:27:
>>>>
>>>> 
>>>>
>>>> Hi Filip,
>>>>
>>>>
>>>>
>>>> I think it is a bit more involved.
>>>>
>>>>
>>>>
>>>> There is an active proposal going into that direction:
>>>>
>>>>
>>>>
>>>> https://github.com/cplusplus/papers/issues/868
>>>>
>>>> P2142 Allow '.' operator to work on pointers
>>>>
>>>>
>>>>
>>>> Perhaps you can cooperate?
>>>>
>>>>
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> *Von:* Filip via Std-Proposals <std-proposals_at_[hidden]>
>>>> *Gesendet:* Fr 31.01.2025 11:23
>>>> *Betreff:* [std-proposals] Possible deprecation of -> operator
>>>> *An:* std-proposals_at_[hidden];
>>>> *CC:* Filip <fph2137_at_[hidden]>;
>>>> Hi everyone,
>>>>
>>>> I’m wondering about the possibility of removal or deprecation of ->
>>>> operator in favor of automatic dereference by ‘.’
>>>>
>>>> If I remember correctly in tcc, compiler has a single if to check if
>>>> they are used correctly and could automatically use the correct operation.
>>>>
>>>> Are there any good reasons to keep that syntax?
>>>> In my experience it’s just an annoying part of early c that is
>>>> maintained.
>>>>
>>>> Cheers,
>>>> Filip
>>>>
>>>> Cheers, Filip
>>>>
>>>> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>>
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>