Version 1.1 of ais/ai-00338.txt

Unformatted version of ais/ai-00338.txt version 1.1
Other versions for file ais/ai-00338.txt

!standard 3.07.02 (02)          03-07-31 AI95-00338/00
!class amendment 03-07-31
!status received 03-01-13
!priority Low
!difficulty Easy
!subject Constrained attribute for generic formal private types
!summary
!problem
!proposal
!wording
!example
!discussion
!corrigendum 03.07.02(02)
!ACATS test
!appendix

!topic constrained attribute for generic formal private types
!reference RM95-3.7.2/2
!from Dan Eilers 03-01-13
!discussion


RM95 3.7.2/2 appears to disallow 'constrained on objects of a
generic formal private type, such as:

    generic
       type T (<>) is private;
    package P is
       pragma elaborate_body;
    end P;

    package body P is
       procedure p1 (x: out T) is
       begin
          if x'constrained ...          -- why not?
       end p1;
    end P;


It seems useful to allow this, presumably yielding true for
actual types for which 'constrained is currently disallowed.

****************************************************************

From: Christoph Grein
Sent: Wednesday, January 15, 2003  1:33 AM

Gnat 3.16w compiles this (with a warning that x is never assigned a value), in
contradiction to 3.7(8/1).

****************************************************************

From: Randy Brukardt
Sent: Thursday, July 31, 2003  5:41 PM

Sorry about commenting on an ancient issue, but I needed to get it on the
record:

> !topic constrained attribute for generic formal private types
> !reference RM95-3.7.2/2
> !from Dan Eilers 03-01-13
> !discussion
>
>
> RM95 3.7.2/2 appears to disallow 'constrained on objects of a
> generic formal private type, such as:
>
>     generic
>        type T (<>) is private;
>     package P is
>        pragma elaborate_body;
>     end P;
>
>     package body P is
>        procedure p1 (x: out T) is
>        begin
>           if x'constrained ...          -- why not?
>        end p1;
>     end P;
>
> It seems useful to allow this, presumably yielding true for
> actual types for which 'constrained is currently disallowed.

This is allowed (in fact required) by J.4 The Constrained Attribute

S'Constrained is in fact defined for all private subtypes.

The AARM claims it is obsolete because Ada 95 has
unknown_discriminant_parts. Precisely why a compile-time feature would
obsolete a useful run-time feature is never quite explained. :-)

Anyway, there is no issue here (unless someone wants to argue that the
attribute shouldn't be obsolete).

****************************************************************

From: Randy Brukardt
Sent: Thursday, July 31, 2003  6:10 PM

I said:

> This is allowed (in fact required) by J.4 The Constrained Attribute
>
> S'Constrained is in fact defined for all private subtypes.

Oops -- he asked for this on an object, not on a subtype.

It's interesting that these two definitions of the Constrained attribute
were taken almost unchanged from Ada 83.

Anyway, defining this on a generic formal private object is somewhat
confusing (as noted in J.4 of the AARM). If the formal type is instantiated
with a scalar subtype without constraints, Obj'Constrained would return
True. But the language says that such a type (and thus such an object) is
unconstrained. As J.4 says, the attribute really would be
'Constrained_or_Elementary.

Given this, I think we need a little more justification for the need of this
attribute; it's possible that we need something other than 'Constrained to
fill the need.

****************************************************************

From: Tucker Taft
Sent: Thursday, July 31, 2003  6:01 PM

Unfortunately, I don't think your response is "responsive" ;-).

The Constrained attribute in Annex J is a compile-time (well, really
an instantiation-time) attribute of private *subtypes*.
Dan is asking about the Constrained attribute on *objects*
which is non-obsolete and is defined in 3.7.2.

Dan's point is there is no harm in allowing the Constrained
attribute to apply to types with unknown discriminants.
Currently it is limited to *discriminated* types, i.e.
types with known discriminants.  I would agree there seems
no harm in allowing this attribute more generally, and it
would only yield False if the actual type happens to have
discriminants and the discriminants of the actual object or
parameter can be altered by an assignment.

The wording might be a bit tricky...

****************************************************************

From: Randy Brukardt
Sent: Thursday, July 31, 2003  6:16 PM

> Unfortunately, I don't think your response is "responsive" ;-).

You should have at least waited for my retraction. :-)

...
> The wording might be a bit tricky...

That's right, but as is pointed out by you or Bob in J.4, that doesn't
correspond to the meaning of "constrained" in Ada 95. It seems odd to define
a non-obsolete Constrained attribute to return something other than whether
the object is constrained or not.

The problem really is with the use of the constrained terminology in Ada 95
("constrained" for composite types is very different than "constrained" for
elementary types, and probably shouldn't use the same name), but it's too
late to change that.

The concept that you've defined is really "Mutable", not "Constrained". It's
unfortunate that mutable never got defined in the language standard, since it
is a much more useful concept.

****************************************************************

From: Tucker Taft
Sent: Thursday, July 31, 2003  7:24 PM

Or to be precise, 'Constrained => not 'Mutable.

In your discussion, I think you are still confusing
the subtype'Constrained and the object'Constrained.
The stuff in the annex J AARM is all about the subtype'Constrained
attribute.

The object'Constrained attribute is currently only defined on discriminated
types.  Generalizing it to be defined on all *composite* types
seems reasonable, remembering that the private view of a type is
considered composite.  The tricky part is defining what it would
mean in the instance (or the private part in the case of a "package private"
type), where the actual/full type is not composite.  It seems simplest
to say that the (composite) private view of an elementary object
is always considered 'Constrained.

****************************************************************

From: Randy Brukardt
Sent: Thursday, July 31, 2003  8:29 PM

> The tricky part is defining what it would mean in the instance (or the
> private part in the case of a "package private" type), where the
> actual/full type is not composite.  It seems simplest
> to say that the (composite) private view of an elementary object
> is always considered 'Constrained.

Of course. And that is what I was objecting to, since the object is not
constrained in language terms. That is:

    Obj'Constrained /= Obj is a constrained object

That seems confusing. Heck, that IS confusing -- they read identically to
me. Moreover, that seems to be the primary reason that S'Constrained was
made obsolete. (The other reason boils down to it not being as useful as it
was, but that hardly is a reason for obsoleting something.)

In any case, we need a !problem for this amendment, and so far, all we have
is that "it seems reasonable", which is not a reason for any amendment. We
need some problem that can't be solved without some language change, and
then we can see if this is the best way to solve the problem. Otherwise,
this is just a solution in search of a problem.

****************************************************************


Questions? Ask the ACAA Technical Agent