discriminants and derived types Q

discriminants and derived types Q

[tmoran]

I have two compilers that accept this package spec, and one that complains
about child3, though it accepts child1 and child2.  Who's right and why?

package testsd is

  type parent1(a,b:integer) is record null;end record;
  type child1(b:integer) is new parent1(a=>1,b=>b);

  type parent2(a,b:integer) is tagged null record;
  type child2(b:integer) is new parent2(a=>1,b=>b) with null record;

  type parent3(a,b:integer) is tagged null record;
  type child3(b:integer) is new parent3(a=>1,b=>b) with private;
                           --   ^  error point

private
  type child3(b:integer) is new parent3(a=>1,b=>b) with null record;

end testsd;

testsd.ads:10:33:  Only static constraints allowed for parent
discriminants in the partial view

Re: discriminants and derived types Q

[Robert I. Eachus]

tmoran@acm.org wrote:
> I have two compilers that accept this package spec, and one that complains
> about child3, though it accepts child1 and child2.  Who's right and why?

GNAT is right. RM 3.7.1(7) says:

A discriminant_constraint is only allowed in a subtype_indication whose 
subtype_mark denotes either an unconstrained discriminated subtype, or 
an unconstrained access subtype whose designated subtype is an 
unconstrained discriminated subtype.

This paragraph was extended by 8652/0008 (AI95-168) but that added 
sentence only has to do with access discriminants.  But you forgot the 
most important question, how should you fix it?

Remove the discrimint constraint in the visible part of the package.  It 
only duplicates the constraint in the private part:

  package testsd is

    type parent1(a,b:integer) is record null;end record;
    type child1(b:integer) is new parent1(a=>1,b=>b);

    type parent2(a,b:integer) is tagged null record;
    type child2(b:integer) is new parent2(a=>1,b=>b) with null record;

    type parent3(a,b:integer) is tagged null record;
    type child3(b:integer) is new parent3 with private;

  private
    type child3(b:integer) is new parent3(a=>1,b=>b) with null record;

  end testsd;

If it bothers you that you can't have the discriminant constraint public 
and the record extension private, it is a safety issue.  Allowing 
non-static discriminants to appear in two different scopes can cause 
"interesting" problems.  The overload resolution as such is not a 
problem, but the expressions involved could evaluate differently in the 
different scopes, even though they appear identical at compile time.  So 
the rule says you can't different discriminant constraints for different 
views of a type.  The alternative would be to have the compiler prove 
that the constraints are identical and reject them otherwise.  Not worth 
the agony.

Note that the workings of the rule in this case are a bit funny.  It 
would seem that the public view of the type is unconstrained.  But 
because the record extension is private, you can only assign to the 
object as a whole in the private part, the body, or other places where 
the private view is visible.  But in all these places, the type is 
constrained, so assignment can never change the discriminants.