Re: Discriminants of tagged types

[Adam Beneschan <adam@irvine.com>]

On Oct 27, 6:44 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Maciej Sobczak <see.my.homep...@gmail.com> writes:
> > GNAT says that discriminants of tagged types cannot have default
> > values.
>
> Well, Ada says that.  GNAT is just following orders.  ;-)
>
> > but this is an error:
>
> >    type T (A : Integer := 0) is tagged null record;
>
> We tried very hard during Ada 9X to allow this, but
> we kept running into semantic difficulties, which required
> more and more complicated rules to fix.  One day,
> Tucker said to me (or I said to Tucker -- I don't
> remember which), let's just outlaw this.  We both
> agreed it was a big simplification.
>
> Sorry, I don't remember in detail what the semantic
> difficulties were.  Ludovic's explanation seems
> as good as any.

AARM 3.7(9.d): "Defaults for discriminants of tagged types are
disallowed so that every object of a tagged type is constrained,
either by an explicit constraint, or by its initial discriminant
values. This substantially simplifies the semantic rules and the
implementation of inherited dispatching operations. For generic formal
types, the restriction simplifies the type matching rules. If one
simply wants a 'default' value for the discriminants, a constrained
subtype can be declared for future use."

One issue with untagged types with default discriminants is that if
you define a type like that:

   type Rec (Discr : Integer := 0) is record ...

and declare a procedure with an IN OUT parameter of that
(unconstrained) type:

   procedure Proc (R : in out Rec) is
   begin
       ...
       R := (Discr => R.Discr + 1, [other components => ...])
          -- whether this is allowed depends on the actual parameter
   end Proc;

you could declare both an unconstrained and constrained object of that
type and pass them both to Proc:

   R1 : Rec;
   R2 : Rec(10);

   Proc (R1);
   Proc (R2);

Proc is allowed to assign a new value to R that changes the
discriminant, but it has to know that if R2 is the actual parameter,
the discriminant is not allowed to change.  This requires additional
information to be passed to Proc so that it knows whether to raise
Constraint_Error when the assignment to R happens.  Apparently it was
felt that where tagged types, class-wide types, and dispatching were
involved, this would make things too complicated.

This may seem "annoying" to those who think that a default
discriminant is *just* a default (rather than creating a different
kind of type that allows the creation of both constrained and
unconstrained objects).  But the last sentence of the AARM note shows
that the workaround is simple enough.  (Personally, I would have
preferred that the two concepts not be mixed, and that there be two
syntaxes---one for specifying a default value for discriminants, and
another to specify that unconstrained objects of the type can be
created.  It's not the only case where having one syntax do "double
duty" ends up causing problems.  I think AI05-154 is a symptom of
this, in which putting a constraint on a nominal array subtype not
only specifies a constraint but also tells the compiler that an
'Access can't be used as an access-to-unconstrained-array value,
causing headaches when you want to include a constraint but *also*
want the ability to have an access-to-unconstrained-array point to the
object; another case, perhaps, where "double duty" may have seemed
like a clever solution to avoid extra syntax, but turned out not to be
such a good idea....   But I'm starting to rant a bit.)

                                     -- Adam