Re: Discriminants of tagged types

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Indeed, this show very well how can default discriminants be a mess (and  
there are other reasons too to add to the ones given here).

A question then come : do someone know something to which default  
discriminants are unavoidable ? I feel default discriminants can simply be  
dropped (kind of sugar?), but I would like to be sure.

The OP asked about the rationale behind the choice to disallow default  
discriminant values in some case. May be to ask about the rationale behind  
the decision to introduce default discriminant values would be worth too.

Le Wed, 27 Oct 2010 17:06:24 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> 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


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.