Date: Fri, 31 Jan 2025 11:28:23 +0000
Hi there Filip,
I can see where you're coming from, but there is still a *lot* of C++ code out there which uses the -> operator and would need rewriting if we were to announce plans to remove it from the language. As such, the reasoning behind deprecating and removing it would have to be really quite important to justify having all of that code rewritten. I'm not sure I personally agree that the burden of writing it is high enough to have a nontrivial percentage of the world's C++ code be put on notice for rewrites. But I see you've been directed to existing papers which propose this so perhaps I'm wrong and there are enough people who would wish to see this change.
While I know that you're concerned about the syntactic burden of using -> at the caller end, another proposal in a tangential space is P3039R0 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3039r0.html), which proposes that an encountered a->b in code can be rewritten as (*a).b, which in turn helps to ease the burden when writing classes with pointer-like semantics. It's not exactly in line with your idea but perhaps it may be of some interest.
I can see where you're coming from, but there is still a *lot* of C++ code out there which uses the -> operator and would need rewriting if we were to announce plans to remove it from the language. As such, the reasoning behind deprecating and removing it would have to be really quite important to justify having all of that code rewritten. I'm not sure I personally agree that the burden of writing it is high enough to have a nontrivial percentage of the world's C++ code be put on notice for rewrites. But I see you've been directed to existing papers which propose this so perhaps I'm wrong and there are enough people who would wish to see this change.
While I know that you're concerned about the syntactic burden of using -> at the caller end, another proposal in a tangential space is P3039R0 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3039r0.html), which proposes that an encountered a->b in code can be rewritten as (*a).b, which in turn helps to ease the burden when writing classes with pointer-like semantics. It's not exactly in line with your idea but perhaps it may be of some interest.
Received on 2025-01-31 11:28:26