Abstract Subprograms of Untagged Types

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Robert A Duff wrote in message ...
|"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
[...]
|>    function Solo_T return Access_Class_T_Type is abstract;
[...]
|> However, the next question is: _why_ is it perfectly legal Ada?  It's
(very
|> nearly) gibberish.
[...]
|The language isn't usually in the business of forbidding useless things.
|Error-prone things, yes.
|
|I think AARM-3.9.3(3.d) addresses the above.


First, to quote the AARM section Bob referred to:

-        3.d   Reason:  We considered disallowing untagged types from having
-        abstract primitive subprograms.  However, we rejected that plan,
-        because it introduced some silly anomalies, and because such
-        subprograms are harmless (if not terribly useful).  For example:

-3.e         package P is
-               type Field_Size is range 0..100;
-               type T is abstract tagged null record;
-               procedure Print(X : in T; F : in Field_Size := 0) is
abstract;
-              . . .
-            package Q is
-               type My_Field_Size is new Field_Size;
-               -- implicit declaration of Print(X : T; F : My_Field_Size :=
0) \
-is abstract;
-            end Q;

-        3.f   It seemed silly to make the derivative of My_Field_Size
-        illegal, just because there was an implicitly declared abstract
-        subprogram that was not primitive on some tagged type.  Other rules
-        could be formulated to solve this problem, but the current ones
seem
-        like the simplest.

Well, just to be crystal clear, I was not seriously criticising this
decision, in my previous post.  I well appreciate the difficulty of making
these kinds of design decisions.

However, while the above 'addresses' the issue, it really resolve it.  I
think the example above can be solved at a stroke by making the rule that an
abstract subprogram is never a primitive operation of an untagged type (it's
legal, but never inherited by derivatives of untagged types).  I think there
needs to be a corollary rule that every abstract subprogram must have at
least one parameter or return type which is a tagged type.  No doubt some
further special rules would be needed.

I've also no doubt that the designers thought of introducing these rules
(alluded to in 3.f), but judged them to add too much complexity to be
worthwhile.  This was a judgement, and fair enough.  However, I disagree
with it, and I would like to see the restrictions introduced in the next
revision of Ada.

I think the reason why can be found in my previous post (in this thread):
users can mistakenly declare abstract subprograms which could actually serve
no useful purpose, but which are quietly accepted by the compiler.
Compilers could be expected to give a warning, but this is at the mercy of
compiler makers (GNAT 3.11p apparently doesn't give any warning, but perhaps
rightly so given the absence of an RM95 implementation recommendation to
that effect).  But, surely it would be better still to force all compilers
to reject such a confusing construct?

Of course compilers cannot be expected to stop programmers from doing silly
things, but they should give a warning (or error) when they can tell the
programmer has (almost certainly) done something silly.

-------------------------------------
Nick Roberts
-------------------------------------