CVS difference for ai12s/ai12-0257-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0257-1.txt

--- ai12s/ai12-0257-1.txt	2020/03/23 03:44:17	1.4
+++ ai12s/ai12-0257-1.txt	2020/06/17 02:35:01	1.5
@@ -2882,7 +2882,71 @@
-From: Yannick Moy
-Sent: Thursday, March 12, 2020  3:50 AM
+From: Tucker Taft
+Sent: Saturday, June 13, 2020  8:38 AM
+In thinking more about AI12-0257-1 on generalizing the object.op() notation, 
+I came up with one pretty simple idea.  Basically, as is true in Ada 2012, 
+if the prefix is of an access type, an implicit dereference would be 
+performed.  This would have the nice effect that in places where the prefix 
+is of a private type, no implicit dereference would happen, whereas where 
+the prefix is visibly of an access type, the implicit dereference *would* 
+be performed.  This seems to nicely solve the upward compatibility problem, 
+as well as allowing it to be used on private types that might be implemented 
+by an access type.
+This does defeat the ability to use prefix notation on primitive operations 
+of a visible access type, but that doesn't seem like a great loss.  It also 
+causes some trouble for default expressions for a "boundary" subprogram (where
+the spec is in a package visible part, and the body sees the full type), if 
+the default expression uses prefix notation for a private type whose full 
+type is an access type.  But using "regular" notation would solve the 
+problem, which also doesn't seem like a big loss.
+The nice thing is that we aren't making any special rules for access types 
+that have a partial view, but rather simply piggy backing on the normal 
+situation that if you can "see" that the prefix is of an access type, then
+an implicit dereference occurs.  If we wanted to be a bit friendlier, we 
+could say that if there are *no* meanings for the selector_name with an 
+implicit dereference, name resolution would try to find a meaning without 
+the implicit dereference, but that could be a second step, since it would 
+not create ambiguity.  It would only make an otherwise illegal use of 
+prefix notation into a legal one.
+Anyway, there were four options identified in the current write-up of 
+AI12-0257-1.  This seems like an interesting fifth alternative.
+From: Tucker Taft
+Sent: Saturday, June 13, 2020  9:14 AM
+Here is some possible wording for this:
+Modify RM 4.1.3(9.1/2-9.2/3):
+  * A view of a subprogram whose first formal parameter is of a [tagged]
+    type {declared immediately within the same declarative region as the
+    subprogram}, or is an access parameter whose designated type is
+    [tagged]{such a type}:
+    The prefix (after any implicit dereference) shall resolve to denote
+    an object or value of a specific [tagged] type T or class-wide type
+    T'Class. The selector_name shall resolve to denote a view of a
+    subprogram declared immediately within the declarative region in
+    which an ancestor of the type T is declared. The first formal
+    parameter of the subprogram shall be of type T, or{, if T is of a
+    tagged type,} a class-wide type that covers T, or an access
+    parameter designating one of these types. The designator of the
+    subprogram shall not be the same as that of a component of the
+    [tagged] type {T} visible at the point of the selected_component.
+    The subprogram shall not be an implicitly declared primitive
+    operation of type T that overrides an inherited subprogram
+    implemented by an entry or protected subprogram visible at the point
+    of the selected_component. The selected_component denotes a view of
+    this subprogram that omits the first formal parameter. This view is
+    called a prefixed view of the subprogram, and the prefix of the
+    selected_component (after any implicit dereference) is called the
+    prefix of the prefixed view.

Questions? Ask the ACAA Technical Agent