Update rfc-class-wide-access-subtype.rst (#2)

Co-authored-by: Vadim Godunko <vgodunko@gmail.com>

Author: reznikmm

considered/rfc-class-wide-access-subtype.rst

@@ -13,6 +13,7 @@ a more precise and clean code, eliminates the need of many extra
 type-conventions and extra subtype declarations. Example:
 
 .. code-block:: ada
+
   type Shape is abstract tagged private;
   type Shape_Access is access all Shape'Class;
   type Cube is new Shape with private;
@@ -41,6 +42,7 @@ As an example let's consider a typical pattern in OOP style. We declare a
 type hierarchy for geomerty shapes and a procedure to register shape objects.
 
 .. code-block:: ada
+
   type Shape is abstract tagged null record;
   type Shape_Access is access all Shape'Class;
   procedure Register (Object : Shape_Access);
@@ -52,6 +54,7 @@ Next code registers a Rectangle and a circle without using a new constraints.
 The first approach uses an extra access type:
 
 .. code-block:: ada
+
   type Rectangle_Access is access all Rectangle;  --  an extra type
   declare
      My_Rectangle : Rectangle_Access := new Rectangle;
@@ -64,6 +67,7 @@ The first approach uses an extra access type:
 The first approach uses an extra type convention:
 
 .. code-block:: ada
+
   declare
      My_Rectangle : Shape_Access := new Rectangle;
   begin
@@ -75,6 +79,7 @@ The first approach uses an extra type convention:
 With new constraint the code is cleaner:
 
 .. code-block:: ada
+
   declare
      My_Rectangle : Shape_Access for access Rectangle := new Rectangle;
   begin
@@ -96,10 +101,6 @@ eliminates several issues with anonymous access types:
 All of these issues could be detected only during execution, and sometimes
 in corner cases only.
 
-----
-Why are we doing this? What use cases does it support? What is the expected
-outcome?
-
 Guide-level explanation
 =======================
 
@@ -111,73 +112,54 @@ designated subtype is a class-wide type.
 With this constraint the author could define subtypes:
 
 .. code-block:: ada
+
    subtype Rectangle_Access is Shape_Access for access Rectangle;
 
 The Rectangle_Access still has Shape_Access type and can be used whereevere
 Shape_Access is expected. In the same time (implicit or explicit) dereferenced value
-denotes Rectangle type (if the acess value is not null).
+denotes Rectangle type (if the access value is not null).
 
 This constraint could be used in other places where constraint is allowed.
 For example,
 
 - in an object declaration:
 
 .. code-block:: ada
+
      My_Rectangle : constant Shape_Access for access Rectangle := new Rectangle;
 
 - in a return object declartion:
 
 .. code-block:: ada
+
   return Result : Shape_Access for access Rectangle := new Rectangle do
      Result.Witch := 10;
      Result.Height := 5;
   end return;
 
-----
-Explain the proposal as if it was already included in the language and you were
-teaching it to another Ada/SPARK programmer. That generally means:
-
-- Introducing new named concepts.
-
-- Explaining the feature largely in terms of examples.
-
-- Explaining how Ada/SPARK programmers should *think* about the feature, and
-  how it should impact the way they use it. It should explain the impact as
-  concretely as possible.
+The same syntax form of the constraint works for class-wide case:
 
-- If applicable, provide sample error messages, deprecation warnings, or
-  migration guidance.
+.. code-block:: ada
 
-For implementation-oriented RFCs (e.g. for RFCS that have no or little
-user-facing impact), this section should focus on how compiler contributors
-should think about the change, and give examples of its concrete impact.
+   subtype Rectangle_Access is Shape_Access for access Rectangle'Class;
 
-For "bug-fixes" RFCs, this section should explain briefly the bug and why it
-matters.
+In this case dereference of the Rectangle_Access value has Rectangle'Class type.
 
 Reference-level explanation
 ===========================
 
 Add to *scalar_constraint* (in 3.2.2) a new rule
 
 .. code-block::
+
   scalar_constraint ::= 
      range_constraint | digits_constraint | delta_constraint
      | class_wide_access_constraint
   
   class_wide_access_constraint ::=
     **for access** *type_*name
 
-----
-This is the technical portion of the RFC. Explain the de# sufficient
-detail that:
-
-- Its interaction with other features is clear.
-- It is reasonably clear how the feature would be implemented.
-- Corner cases are dissected by example.
-
-The section should return to the examples given in the previous section, and
-explain more fully how the detailed proposal makes those examples work.
+Add a corresponding rules for dereferenced values.
 
 Rationale and alternatives
 ==========================
@@ -187,82 +169,23 @@ The nearest feature is anonymous access types, but they have issues (see above).
 In our point of view this new constraint kind fits well with Ada philosophy
 and best practices.
 
-----
-- Why is this design the best in the space of possible designs?
-- What other designs have been considered and what is the rationale for not
-  choosing them?
-- What is the impact of not doing this?
-- How does this feature meshes with the general philosophy of the languages ?
-
 Drawbacks
 =========
 
 None :)
 
-----
-Why should we *not* do this?
-
 Prior art
 =========
 
 This is too Ada specific to have a precedent in other languages, I guess.
 
-----
-Discuss prior art, both the good and the bad, in relation to this proposal.
-
-- For language, library, and compiler proposals: Does this feature exist in
-  other programming languages and what experience have their community had?
-
-- Papers: Are there any published papers or great posts that discuss this? If
-  you have some relevant papers to refer to, this can serve as a more detailed
-  theoretical background.
-
-This section is intended to encourage you as an author to think about the
-lessons from other languages, provide readers of your RFC with a fuller
-picture.
-
-If there is no prior art, that is fine - your ideas are interesting to us
-whether they are brand new or if it is an adaptation from other languages.
-
-Note that while precedent set by other languages is some motivation, it does
-not on its own motivate an RFC.
-
 Unresolved questions
 ====================
 
 None found yet.
 
-----
-- What parts of the design do you expect to resolve through the RFC process
-  before this gets merged?
-
-- What parts of the design do you expect to resolve through the implementation
-  of this feature before stabilization?
-
-- What related issues do you consider out of scope for this RFC that could be
-  addressed in the future independently of the solution that comes out of this
-  RFC?
 
 Future possibilities
 ====================
 
 No other ideas yet.
-
-----
-Think about what the natural extension and evolution of your proposal would
-be and how it would affect the language and project as a whole in a holistic
-way. Try to use this section as a tool to more fully consider all possible
-interactions with the project and language in your proposal.
-Also consider how the this all fits into the roadmap for the project
-and of the relevant sub-team.
-
-This is also a good place to "dump ideas", if they are out of scope for the
-RFC you are writing but otherwise related.
-
-If you have tried and cannot think of any future possibilities,
-you may simply state that you cannot think of anything.
-
-Note that having something written down in the future-possibilities section
-is not a reason to accept the current or a future RFC; such notes should be
-in the section on motivation or rationale in this or subsequent RFCs.
-The section merely provides additional information.