Skip to content

Commit 026f394

Browse files
reznikmmgodunko
andcommitted
Update rfc-class-wide-access-subtype.rst (#2)
Co-authored-by: Vadim Godunko <[email protected]>
1 parent 479b0ff commit 026f394

File tree

1 file changed

+6
-93
lines changed

1 file changed

+6
-93
lines changed

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

Lines changed: 6 additions & 93 deletions
Original file line numberDiff line numberDiff line change
@@ -96,10 +96,6 @@ eliminates several issues with anonymous access types:
9696
All of these issues could be detected only during execution, and sometimes
9797
in corner cases only.
9898

99-
----
100-
Why are we doing this? What use cases does it support? What is the expected
101-
outcome?
102-
10399
Guide-level explanation
104100
=======================
105101

@@ -115,7 +111,7 @@ With this constraint the author could define subtypes:
115111
116112
The Rectangle_Access still has Shape_Access type and can be used whereevere
117113
Shape_Access is expected. In the same time (implicit or explicit) dereferenced value
118-
denotes Rectangle type (if the acess value is not null).
114+
denotes Rectangle type (if the access value is not null).
119115

120116
This constraint could be used in other places where constraint is allowed.
121117
For example,
@@ -133,27 +129,12 @@ For example,
133129
Result.Height := 5;
134130
end return;
135131
136-
----
137-
Explain the proposal as if it was already included in the language and you were
138-
teaching it to another Ada/SPARK programmer. That generally means:
139-
140-
- Introducing new named concepts.
141-
142-
- Explaining the feature largely in terms of examples.
132+
The same syntax form of the constraint works for class-wide case:
143133

144-
- Explaining how Ada/SPARK programmers should *think* about the feature, and
145-
how it should impact the way they use it. It should explain the impact as
146-
concretely as possible.
147-
148-
- If applicable, provide sample error messages, deprecation warnings, or
149-
migration guidance.
150-
151-
For implementation-oriented RFCs (e.g. for RFCS that have no or little
152-
user-facing impact), this section should focus on how compiler contributors
153-
should think about the change, and give examples of its concrete impact.
134+
.. code-block:: ada
135+
subtype Rectangle_Access is Shape_Access for access Rectangle'Class;
154136
155-
For "bug-fixes" RFCs, this section should explain briefly the bug and why it
156-
matters.
137+
In this case dereference of the Rectangle_Access value has Rectangle'Class type.
157138

158139
Reference-level explanation
159140
===========================
@@ -168,16 +149,7 @@ Add to *scalar_constraint* (in 3.2.2) a new rule
168149
class_wide_access_constraint ::=
169150
**for access** *type_*name
170151
171-
----
172-
This is the technical portion of the RFC. Explain the design in sufficient
173-
detail that:
174-
175-
- Its interaction with other features is clear.
176-
- It is reasonably clear how the feature would be implemented.
177-
- Corner cases are dissected by example.
178-
179-
The section should return to the examples given in the previous section, and
180-
explain more fully how the detailed proposal makes those examples work.
152+
Add a corresponding rules for dereferenced values.
181153

182154
Rationale and alternatives
183155
==========================
@@ -187,82 +159,23 @@ The nearest feature is anonymous access types, but they have issues (see above).
187159
In our point of view this new constraint kind fits well with Ada philosophy
188160
and best practices.
189161

190-
----
191-
- Why is this design the best in the space of possible designs?
192-
- What other designs have been considered and what is the rationale for not
193-
choosing them?
194-
- What is the impact of not doing this?
195-
- How does this feature meshes with the general philosophy of the languages ?
196-
197162
Drawbacks
198163
=========
199164

200165
None :)
201166

202-
----
203-
Why should we *not* do this?
204-
205167
Prior art
206168
=========
207169

208170
This is too Ada specific to have a precedent in other languages, I guess.
209171

210-
----
211-
Discuss prior art, both the good and the bad, in relation to this proposal.
212-
213-
- For language, library, and compiler proposals: Does this feature exist in
214-
other programming languages and what experience have their community had?
215-
216-
- Papers: Are there any published papers or great posts that discuss this? If
217-
you have some relevant papers to refer to, this can serve as a more detailed
218-
theoretical background.
219-
220-
This section is intended to encourage you as an author to think about the
221-
lessons from other languages, provide readers of your RFC with a fuller
222-
picture.
223-
224-
If there is no prior art, that is fine - your ideas are interesting to us
225-
whether they are brand new or if it is an adaptation from other languages.
226-
227-
Note that while precedent set by other languages is some motivation, it does
228-
not on its own motivate an RFC.
229-
230172
Unresolved questions
231173
====================
232174

233175
None found yet.
234176

235-
----
236-
- What parts of the design do you expect to resolve through the RFC process
237-
before this gets merged?
238-
239-
- What parts of the design do you expect to resolve through the implementation
240-
of this feature before stabilization?
241-
242-
- What related issues do you consider out of scope for this RFC that could be
243-
addressed in the future independently of the solution that comes out of this
244-
RFC?
245177

246178
Future possibilities
247179
====================
248180

249181
No other ideas yet.
250-
251-
----
252-
Think about what the natural extension and evolution of your proposal would
253-
be and how it would affect the language and project as a whole in a holistic
254-
way. Try to use this section as a tool to more fully consider all possible
255-
interactions with the project and language in your proposal.
256-
Also consider how the this all fits into the roadmap for the project
257-
and of the relevant sub-team.
258-
259-
This is also a good place to "dump ideas", if they are out of scope for the
260-
RFC you are writing but otherwise related.
261-
262-
If you have tried and cannot think of any future possibilities,
263-
you may simply state that you cannot think of anything.
264-
265-
Note that having something written down in the future-possibilities section
266-
is not a reason to accept the current or a future RFC; such notes should be
267-
in the section on motivation or rationale in this or subsequent RFCs.
268-
The section merely provides additional information.

0 commit comments

Comments
 (0)