Re: Proposed change to BC iterator parameters

[Jeffrey Carter <spam@spam.com>]

amado.alves wrote:

> Strictly you don't need the limited formal for (unlimited) tagged or
> class actuals. You need the limited formal for limited actuals,
> whatever their class. Limitedness is completely orthogonal to
> definiteness. I do like indefinite formals, but I pass well without
> limited ones. Most limited formals I've seen in libraries are
> accompanied by a formal assignment operation or some such, which
> prety much defeats the purpose of their (formal) limitedness, i.e.
> their logic is in clash with their definition.

The problem is that a generic formal part is a specification; it 
specifies what the generic needs, and the client must provide, for the 
generic to do its work. "Limited" implies 2 unrelated concepts: absence 
of assignment, and absence of predefined equality. To specify that the 
generic needs to be able to assign objects of a formal type, but does 
not need to perform equality comparisons, can only be done correctly 
with a limited private formal type, and a formal Assign procedure.

A non-limited formal type specifies that the generic needs to perform 
equality comparisons on values of the type, which is an error in 
specification. I know this seems a minor issue to many people, but 
precise specifications are essential to ensuring the correct usage of 
reusable components by their clients.

This connection between assignment and equality may have made sense in 
Ada 83, where equality could only be defined for limited types, but 
seems an unnecessary restriction in Ada 95.

In hindsight, it would have been better to eliminate the "limited" 
reserved word completely, and use instead

type T is private;
-- Same as Ada's "limited private"

type T is private with ":=";
-- Assignment defined; "=" not; no Ada equivalent

with the capability of defining "=" for either type.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10