Date: Sat, 8 Feb 2025 14:57:32 +0000
I've tried to follow this conversation but there is one question that I couldn't get quite understand.
Why?
It's already well-established practice.
.
->
Have 2 different meanings, it's not confusing where you should use one or the other, nor have I ever experienced any downsides to this distinction.
It actually plays a quite nice role in making its use clear.
I can understand removing the ability to overload it.
I agree that the ability to overload every operator went too far to the point where you are not sure what any of those things mean, but that doesn't seem to be the proposal. And one could argue it works quite well in the case of smart pointers.
I would never advocate dereferencing a pointer with the same thing we use to access elements of an object (.)
Does the proposal improve clarity? No.
Does the proposal allows you do something new or solve a problem? No.
Other than "it saves me to type only 1 character instead of 2", what would I as a software developer writing C++ gain from this?
Why?
It's already well-established practice.
.
->
Have 2 different meanings, it's not confusing where you should use one or the other, nor have I ever experienced any downsides to this distinction.
It actually plays a quite nice role in making its use clear.
I can understand removing the ability to overload it.
I agree that the ability to overload every operator went too far to the point where you are not sure what any of those things mean, but that doesn't seem to be the proposal. And one could argue it works quite well in the case of smart pointers.
I would never advocate dereferencing a pointer with the same thing we use to access elements of an object (.)
Does the proposal improve clarity? No.
Does the proposal allows you do something new or solve a problem? No.
Other than "it saves me to type only 1 character instead of 2", what would I as a software developer writing C++ gain from this?
Received on 2025-02-08 14:57:35