[Solved]: Why is there readonly (const) in C++, but not writeonly (sink)?

If the question is interpreted in the historical way (as done by Wandering Logic), then the answer can indeed by found in “Bjarne Stroustrup, The Design and Evolution of C++” in section “3.8 Constants”. The readonly and writeonly qualifiers were proposed in January 1981 by Stroustrup as a modification of the C language (not of the C with classes language), long before C++ even existed (but C with classes already existed and was mature). An internal Bell Labs C standards group requested that readonly be renamed to const, and agreed that it would be introduced into C then (which somehow didn’t happen at the time). Stroustrup waited for this to happen, and in the meantime discovered that const could also be used to provide symbolic constants (the parameter keyword in fortran). The proposal for writeonly was not well worked out, didn’t provide additional use cases beyond its main purpose in function interfaces, and wasn’t accepted by the internal standard group. So writeonly wasn’t removed by a conscious decision, but just didn’t manage to convince enough people of its usefulness. Because Stroustrup still brings up writeonly when describing const, we can even guess that he’s still proud of his initial idea.

What are the problems with writeonly (or a “sink” qualifier)?

• For a language like C with ++ and += operators that return references to the modified object, the question whether this returned reference should be write only is difficult to resolve. The reference returned by the += operator should probably be a sink, but some uses of ++ need a non-sink returned reference.
• An appropriate formal semantic of a sink qualifier is not obvious, and Stroustrup didn’t work out a satisfying formal semantic either.
• Even without exceptions, error handling becomes problematic and surprising. As a real world example, I remember me debugging through a “write only” “progress provider”, which triggered a GUI update and thereby caused a cancel button to propagate its state to a “cancel provider”. If the “progress provider” was replaced by a dummy implementation (when no progress was desired for certain use case), suddenly that “cancel provider” stopped working correctly. An this was even harmless compared to another “progress provider”, which just took care of the cancel functionality himself by throwing an exception, thereby crashing the program in many multithreaded and distributed scenarios.
  These two examples show some of the real world issues that a sink qualifier should address. But this is a much more tricky problem compared to the problems solved by const, and it is not clear how a formal semantic resolving these issues can look like.
• ??? (I forgot for the moment, maybe I will remember later)

But so what, does anything bad happens if “result_p = result_p+1” is not allowed?

The answer by Wandering Logic and his reaction to requests for clarification in the comments provide good examples for the bad things that would happen:

• “An append operation for vectors most certainly can not be writeonly, because it must increment the length of the vector (i.e., length = length+1.)”
• “I’m glad Stroustrup didn’t invent a language where x+=1 has different type than x=x+1”

Having a half baked language feature would only lead to confusion and frustration, which could never be outweighed by the benefits of the feature. So if one would want such a sink feature, then one also needs a formal semantic which closely models the intended (informal) semantic. Some sort of preorder on the accessible references seems required, which determines how information is allowed to flow. But can this preorder always be generated implicitly, or does the programmer sometimes need to also specify details of this preorder? But this all seems to be quite complicated for the limited benefits provided by a sink modifier.