Date: Thu, 13 Aug 2026 02:27:21 +0200
From what I've read, this is to avoid errors caused by reuse added later.
My thoughts. I never heard a wish about such a feature, so they may be incomplete.
1: Error prevention through a mechanism that must be used manually doesn't seem very promising to me, because that mechanism must also be used correctly.
2: Why should the creator of the variable decide this, rather than the user? the same as class final (without virtuals). So something opposite to "forget" will be needed.
3: The embedded question of how often this kind of mistake actually occurs is not answered. It happened so rarely that I didn't realize it was a problem in and of itself.
4: The embedded question of the effort required to use such a mechanism is not answered. Will the code then be full of "forget" statements? And, as a result, full of "anti-forget" statements?
5: "Forget" has a convenience factor. Every convenience leads to a certain mindset. This will result in less attention being paid to changes and additions, since the original author will have already taken care of that.
6: Every convenience also leads to a reduction in learning outcomes and a reduction in pattern recognition — in this case regarding specific errors. This will lead to mental debt (similar to technical debt).
7: A system like this for the proposed "forget" carries a residual risk: A system that works only partially due to a lack of awareness of its failure. If I do know about it, it’s because I’ve looked at it. If I have to search for "forget" first, I might as well just look at how the variable is used. Only then I am safe.
The arguments mentioned so far are very very far too weak to outweigh these concerns.
8: There are more important issues to address, such as generating error messages for the program's users.
My thoughts. I never heard a wish about such a feature, so they may be incomplete.
1: Error prevention through a mechanism that must be used manually doesn't seem very promising to me, because that mechanism must also be used correctly.
2: Why should the creator of the variable decide this, rather than the user? the same as class final (without virtuals). So something opposite to "forget" will be needed.
3: The embedded question of how often this kind of mistake actually occurs is not answered. It happened so rarely that I didn't realize it was a problem in and of itself.
4: The embedded question of the effort required to use such a mechanism is not answered. Will the code then be full of "forget" statements? And, as a result, full of "anti-forget" statements?
5: "Forget" has a convenience factor. Every convenience leads to a certain mindset. This will result in less attention being paid to changes and additions, since the original author will have already taken care of that.
6: Every convenience also leads to a reduction in learning outcomes and a reduction in pattern recognition — in this case regarding specific errors. This will lead to mental debt (similar to technical debt).
7: A system like this for the proposed "forget" carries a residual risk: A system that works only partially due to a lack of awareness of its failure. If I do know about it, it’s because I’ve looked at it. If I have to search for "forget" first, I might as well just look at how the variable is used. Only then I am safe.
The arguments mentioned so far are very very far too weak to outweigh these concerns.
8: There are more important issues to address, such as generating error messages for the program's users.
-- Die Moral von der Geschicht': Spiel' nach den Regeln des Gegners nicht. http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
Received on 2026-08-13 00:27:32