Extend motivation and use cases section

Author: aradi

proposals/protected_attribute.txt

@@ -28,15 +28,20 @@ instance. While in the setter routine the copying serves robustness by
 "disentangling" the data stored in the derived type from the original data, the
 getter routine and the connected copy operation might be superfluous, when the
 consumer only wants to read but not modify the data stored in the derived type
-intance.  By allowing for a direct read-only access, one could enhance
-efficiency in those case without sacrificing the robustness of data
-encapsulation and hiding.
+intance.
+
+By allowing for a direct read-only access, one could enhance efficiency in those
+cases without sacrificing the consistency of the encapsulated data. Direct
+access is possible with current Fortran already, but only if the respective
+derived type component is public. This would jeopardize data consistency,
+though, as a consumer could change the respective component arbitrarily, without
+using the provided setter routine.
 
 This proposal suggests to allow the "protected" attribute already used for
 module variables being used for derived type components as well. It would also
 remedy the asymmetry between the attributes "private"/"public" and the attribute
 "protected", as the former two can be applied to both, module variables and
-derived type components, while the latter only for module variables.
+derived type components, while the latter only for module variables so far.
 
 
 3. Use Cases
@@ -86,4 +91,9 @@ operation:
     ! Dummy argument of the called routine must be intent(in)
     call some_routine_processing_but_not_changing_the_array(storage%array)
 
+    ! Inconsistent change, consumer is supposed to call set() to change
+    ! encapsulated data.
+    ! Uncommenting the next line should trigger a compiler error.
+    !storage%array(1) = -1
+
   end program use_data