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 at 1:04 AM Jonathan Wakely <cxx@kayari.org> wrote:On Sun, 2 Feb 2025, 07:00 J Decker via Std-Proposals, <std-proposals@lists.isocpp.org> 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, andWhat 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@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Fr 31.01.2025 11:33
Betreff: Re: [std-proposals] Possible deprecation of -> operator
An: std-proposals@lists.isocpp.org;
CC: Filip <fph2137@gmail.com>;
Hi thanks for that link, I will try and help with this.Cheers, FilipWiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Fr 31.01.2025 11:23
Betreff: [std-proposals] Possible deprecation of -> operator
An: std-proposals@lists.isocpp.org;
CC: Filip <fph2137@gmail.com>;
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,
FilipCheers, Filip-- Std-Proposals mailing list Std-Proposals@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals-- Std-Proposals mailing list Std-Proposals@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals