Version 1.1 of ai05s/ai05-0102-1.txt

Unformatted version of ai05s/ai05-0102-1.txt version 1.1
Other versions for file ai05s/ai05-0102-1.txt

!standard 4.6(24.12/2) 08-06-15 AI05-0102-1/01
!standard 5.2(11)
!class binding interpretation 08-06-15
!status work item 08-06-15
!status received 06-04-24
!priority Low
!difficulty Medium
!qualifier Omission
!subject Some implicit conversions ought to be illegal

!summary

**TBD.

!question

Consider the following:

declare VObj : access Designated := ...; CObj : access constant Designated := ...; Cnst : aliased constant Designated := ...; begin VObj := Cnst'access; -- (1) VObj := CObj; -- (2) end;

(1) is illegal by 3.10.2(25).

Surely we want (2) to be illegal, too, but there doesn't seem to be any rule that covers it.

!wording

** TBD.

!discussion

The only way to see this as illegal now is to use the dynamic semantics rule 5.2(11), which says that the result is converted, and then note that 4.6(24.12/2) says that this conversion is illegal. But it is very unconfortable depending on a dynamic semantics rule to trigger a legality error, especially as the rule talks about raising an exception but not an error.

The way forward is not clear here (there are other places than assignment that need to be considered).

--!corrigendum 5.2(11)

!ACATS Test

!appendix


From: Randy Brukardt
Sent: Thursday, April 24, 2008  10:01 PM

Can an implicit subtype conversion be illegal (not just raise an exception)?
Channeling Adam, I'm not sure. (I am sure what answer we want, so the only
question is whether the Standard actually justifies that answer.)

Consider the following from an ACATS test now under construction:

    declare
        VObj : access Designated := ...;
        CObj : access constant Designated := ...;
        Cnst : aliased constant Designated := ...;
    begin
        VObj := Cnst'Access;   -- ERROR: (1)
        VObj := CObj;          -- ERROR: (2)
    end;

While I'm certain that we want (2) to be illegal, I'm having trouble justifying
it based on the wording of the Standard.

(1) resolves because the type of the access attribute is that of the expected
type; but it is illegal because it violates 3.10.2(25).

(2) resolves because of 8.6(25/2), which allows these otherwise different types
to match. So no error there. We turn to 5.2's Legality Rules. 5.2(5/2) is
satisfied because the target is a variable. 5.2(6) doesn't apply (VObj isn't
tagged). So why is this illegal?

The only hope resides in the Dynamic Semantics rules, which is not a likely
place to look for rules that make things illegal! The rule is 5.2(11): the value
is converted to the subtype of the target. One can then say that the legality
rule 4.6(24.12/2) applies. But this is weird, because (a) it mentions the
possibility of an exception, but not illegality; (b) it's not clear if the
original type of the value is considered or not; (c) it's not clear that
an actual *type* conversion is possible. (Yes, I know that there are no
named types in Ada [everything is a subtype], but these aren't named anyway... :-).

I think we should at least have a To Be Honest note in the AARM that this
implicit subtype conversion can be illegal in cases involving anonymous types,
and it can convert types, not just subtypes, in such cases. It would be better
for there to be an explicit statement of that fact somewhere (it probably isn't
practical to put it everywhere that it can happen: there is a half a column of
references for "implicit subtype conversion" in the RM's index; but the
assignment case is the most common one).

Do I have the intent right here, or have I missed something??

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

From: Robert A. Duff
Sent: Friday, April 25, 2008  7:47 AM

> The only hope resides in the Dynamic Semantics rules, which is not a 
> likely place to look for rules that make things illegal!

Indeed, we can't use Dynamic Semantics to say something is illegal!

Implicit things being illegal seems uncomfortable anyway.  Seems like we're 
missing a rule.

The fact that converting to a subtype can convert the type as well is not new.
It is used for example in the semantics of calls to inherited subprograms.

4.6(58) seems relevant:

58    Conversion to a type is the same as conversion to an unconstrained
subtype of the type.

    58.a  Reason: This definition is needed because the semantics of various
          constructs involves converting to a type, whereas an explicit
          type_conversion actually converts to a subtype. For example, the
          evaluation of a range is defined to convert the values of the
          expressions to the type of the range.

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

Questions? Ask the ACAA Technical Agent