Revision of direct attribute definitions

Author: Denis Mazzucato

features/rfc-oop-attributes.rst

@@ -11,7 +11,10 @@ Motivation
 Guide-level explanation
 =======================
 
-Today, specifying a subprogram attribute of a type requires to declare a
+Direct Attribute definitions
+----------------------------
+
+Currently, specifying a subprogram attribute of a type requires to declare a
 subprogram and then to use an aspect or an attribute to link it to a type, e.g.
 
 .. code-block:: ada
@@ -20,44 +23,174 @@ subprogram and then to use an aspect or an attribute to link it to a type, e.g.
 
    for T'Write use My_Write;
 
-   procedure My_Write(
-      Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+   procedure My_Write
+     (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+      Item : in T);
+
+Or directly into the type declaration via an aspect specification
+
+.. code-block:: ada
+
+   type T is null record with Write => My_Write;
+
+   procedure My_Write
+     (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
       Item : in T);
 
-This proposal allows to define directly the procedure as being an attribute of
-the type:
+This proposal introduces *direct attribute definitions* that allows to define
+directly the procedure as being an attribute of the type:
 
 .. code-block:: ada
 
    type T is null record;
 
-   procedure T'Write(
-      Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+   procedure T'Write
+     (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
       Item : in T);
 
-In addition, this can be used as a scoped attribute, possibly with re-ordering
-of parameters to ensure that the first parameter is conceptually the one
-"owning" the primitive, e.g.:
+In addition, this can be used within scoped records, e.g.:
 
 .. code-block:: ada
 
    type T is tagged record
 
-      procedure T'Write(
-         Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+      procedure T'Write
+        (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
          Item : in T);
 
    end T;
 
-This provide a seamless solution in particular to scope a destructor:
-
+This provide a seamless solution in particular to scope oop primitives:
 
 .. code-block:: ada
 
-   type T is tagged record
+   type T is class record
+      procedure T'Constructor (Self : in out T);
       procedure T'Destructor (Self : in out T);
    end record;
 
+Unfortunately, the direct attribute definitions inside a scoped record clashes
+with the class type rules where each subprogram is required to be primitive
+following the rules of First_Controlling_Parameter (e.g., see `T'Write` above
+where `Item` is the second formal). The rule's motivation comes from the idea
+that class' primitives are called with the prefix notation.
+
+To solve this conflict, we could either:
+
+1. Re-order parameters to ensure that the first parameter is conceptually the
+   one "owning" the primitive. We do so by moving to front the first occurrence
+   of a formal with the same type of the record  scope it is declared in. The
+   example above would then extend to:
+
+   .. code-block:: ada
+
+      type T is tagged record
+
+         procedure Internal_T_Write (
+            Item : in T;
+            Stream : not null access Ada.Streams.Root_Stream_Type'Class);
+
+      end T;
+
+      procedure Reordered_Internal_T_Write (
+         Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+         Item : in T) is
+      begin
+         Item.Internal_T_Write (Stream);
+      end Reordered_Internal_T_Write;
+
+      for T'Write use Reordered_Internal_T_Write;
+
+2. Otherwise, given that attribute calls (such as `T'Write (S, I)` in a
+   statement) are somehow different from subprogram calls and will not employ a
+   prefixed notation even when defined in the scoped record, then it could make
+   sense to remove the burden of the First_Controlling_Parameter for such
+   entities.
+
+In short, the first approach is less clean and a bit cumbersome when no formal
+is of the enclosing type (a new unused one could be introduced). The second
+approach threats differently attribute definitions from the others, exceptions
+may create complexity in the implementation side.
+
+Direct Aspect definitions
+-------------------------
+
+So far only a small set of attributes denote callable subprograms: stream and
+I/O operations. However, a similar shorthand definition envisioned in this rfc
+could be useful as is for aspects. For instance, we could define a container
+as:
+
+.. code-block:: ada
+
+   type Indexable_Container is tagged record
+
+      function Indexable_Container'Constant_Indexing
+        (Container : aliased Indexable_Container;
+         Position  : Offset) return Constant_Reference_Type;
+
+      function Indexable_Container'Constant_Indexing -- overloading
+        (Container : aliased Indexable_Container;
+         Position  : Custom_Offset) return Constant_Reference_Type;
+
+      function Indexable_Container'Variable_Indexing
+        (Container : aliased in out Indexable_Container;
+         Position  : Offset) return Reference_Type;
+
+   end record;
+
+That expands to the aspects named `Constant_Indexing` and `Variable_Indexing`
+respectively.
+
+Apart from the benefit of grouping locally all operations together, and remove
+the need of temporary subprograms, the shorthand for aspects removes all
+together the class of errors from name resolution rules. For example, we don't
+need to worry of `Indexable_Container'Constant_Indexing` homonyms since that
+name doesn't clash with anything else other than its second overloading, but a
+mismatch in the profile would be easy to spot in that case.
+
+This inline notation could be shortened further, potential candidates are:
+
+- Usage of `@'Attribute` since `@` can be resolved to the enclosing record name
+  similarly to the shorthand for the left hand side of assignments. The big
+  advantage is when the record name is a bit cumbersome. We could rewrite the
+  container above as:
+
+  .. code-block:: ada
+
+      type Indexable_Container is tagged record
+
+         function @'Constant_Indexing
+           (Container : aliased @;
+            Position  : Offset) return Constant_Reference_Type;
+
+         function @'Constant_Indexing
+           (Container : aliased @;
+            Position  : Custom_Offset) return Constant_Reference_Type;
+
+         function @'Variable_Indexing
+           (Container : aliased in out @;
+            Position  : Offset) return Reference_Type;
+
+      end record;
+
+   More in general, the `@` symbol could be used anywhere in the scoped record
+   resolving to the record name. Another example with the `Aggregate` aspect
+   would look like the following:
+
+   .. code-block:: ada
+
+      type Container_Type (Cap : Positive) is tagged private
+
+         function @'Aggregate'Empty (Cap : Positive) return @;
+
+         procedure @'Aggregate'Add_Unnamed (Self : in out @; New_Item : T);
+
+      end record;
+
+- Or, the usage of just `'Attribute`` without the prefix name when inside
+  scoped records. This second notation would only avoid writing the record name
+  once, thus less preferred than the option above.
+
 Reference-level explanation
 ===========================