@@ -96,10 +96,6 @@ eliminates several issues with anonymous access types:
96
96
All of these issues could be detected only during execution, and sometimes
97
97
in corner cases only.
98
98
99
- ----
100
- Why are we doing this? What use cases does it support? What is the expected
101
- outcome?
102
-
103
99
Guide-level explanation
104
100
=======================
105
101
@@ -115,7 +111,7 @@ With this constraint the author could define subtypes:
115
111
116
112
The Rectangle_Access still has Shape_Access type and can be used whereevere
117
113
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).
119
115
120
116
This constraint could be used in other places where constraint is allowed.
121
117
For example,
@@ -133,27 +129,12 @@ For example,
133
129
Result.Height := 5;
134
130
end return;
135
131
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:
143
133
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;
154
136
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.
157
138
158
139
Reference-level explanation
159
140
===========================
@@ -168,16 +149,7 @@ Add to *scalar_constraint* (in 3.2.2) a new rule
168
149
class_wide_access_constraint ::=
169
150
**for access** *type_*name
170
151
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.
181
153
182
154
Rationale and alternatives
183
155
==========================
@@ -187,82 +159,23 @@ The nearest feature is anonymous access types, but they have issues (see above).
187
159
In our point of view this new constraint kind fits well with Ada philosophy
188
160
and best practices.
189
161
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
-
197
162
Drawbacks
198
163
=========
199
164
200
165
None :)
201
166
202
- ----
203
- Why should we *not * do this?
204
-
205
167
Prior art
206
168
=========
207
169
208
170
This is too Ada specific to have a precedent in other languages, I guess.
209
171
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
-
230
172
Unresolved questions
231
173
====================
232
174
233
175
None found yet.
234
176
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?
245
177
246
178
Future possibilities
247
179
====================
248
180
249
181
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