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

Co-authored-by: Vadim Godunko <[email protected]>

Author: reznikmm

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

@@ -96,10 +96,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
 =======================
 
@@ -115,7 +111,7 @@ With this constraint the author could define subtypes:
 
 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,
@@ -133,27 +129,12 @@ For example,
      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.
+The same syntax form of the constraint works for class-wide case:
 
-- 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.
-
-- If applicable, provide sample error messages, deprecation warnings, or
-  migration guidance.
-
-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.
+.. code-block:: ada
+   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
 ===========================
@@ -168,16 +149,7 @@ Add to *scalar_constraint* (in 3.2.2) a new rule
   class_wide_access_constraint ::=
     **for access** *type_*name
 
-----
-This is the technical portion of the RFC. Explain the design in 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 +159,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.