Version 1.8 of ai12s/ai12-0096-1.txt

Unformatted version of ai12s/ai12-0096-1.txt version 1.8
Other versions for file ai12s/ai12-0096-1.txt

!standard 4.6(57/3)          14-09-29 AI12-0096-1/02
!class binding interpretation 14-02-12
!status Corrigendum 1-2012 14-07-14
!status WG9 Approved 14-10-20
!status ARG Approved 8-0-0 14-06-28
!status work item 14-02-12
!status received 13-12-16
!priority Low
!difficulty Easy
!qualifier Omission
!subject The exception raised when a subtype conversion fails a predicate check
!summary
A subtype conversion that fails a predicate check has the effect defined in 3.2.4; it does not unconditionally raise Assertion_Error.
!question
4.6(57/3) says:
If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails, Assertions.Assertion_Error is raised. Any other check associated with a conversion raises Constraint_Error if it fails.
However, AI12-0054-2 defines the Predicate_Failure aspect, which can change what exception is raised when a predicate check fails. Do we need to adjust this wording? (Yes.)
!recommendation
(See Summary.)
!wording
Modify 4.6(57/3):
If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails, {the effect is as defined in subclause 3.2.4, "Subtype Predicates"}[Assertions.Assertion_Error is raised]. Any other check associated with a conversion raises Constraint_Error if it fails.
!discussion
Surely we don't want one set of rules for the effect of a predicate check in 3.2.4 and a different set in 4.6. The fact that this is the case is clearly an oversight (which has occurred repeatedly with this paragraph).
We don't want to repeat the relatively complex rules for the evaluation of the Predicate_Failure aspect anywhere, so we simply refer to them here. (At least that will eliminate one potential problem in the future.)
!corrigendum 4.6(57/3)
Replace the paragraph:
If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails, Assertions.Assertion_Error is raised. Any other check associated with a conversion raises Constraint_Error if it fails.
by:
If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails, the effect is as defined in subclause 3.2.4, "Subtype Predicates". Any other check associated with a conversion raises Constraint_Error if it fails.
!ASIS
No ASIS effect.
!ACATS test
No separate test is needed as a C-Test for the Predicate_Failure aspect would almost certainly test this (95% of predicate checks occur on subtype conversions).
!appendix

From: Randy Brukardt
Sent: Monday, December 16, 2013  10:24 PM

4.6(57/3) says:

If an Accessibility_Check fails, Program_Error is raised. If a predicate check
fails, Assertions.Assertion_Error is raised. Any other check associated with a
conversion raises Constraint_Error if it fails.

This was a last-minute fix so that predicate checks in type conversions would
do the right thing. However, now that we've changed the "right thing" to depend
on the Predicate_Failure aspect, we need to change this wording in a similar
way. 

Probably we need something like:

   If a predicate check fails, the effect is as defined in subclause 3.2.4,
   "Subtype Predicates".

because it makes no sense to duplicate any of the failure wording here.
(Perhaps an AARM note explaining that Assertion_Error is raised in the absence
of a Predicate_Failure aspect would be helpful. Or maybe instead of "the effect
is as defined...", we should say "an exception is raised as defined...")

I doubt anyone would expect anything else (it would violate the Dewar rule, I
think), so this should be a really easy (and low-priority) AI. But we do
need to fix it, because it directly conflicts with the revised wording in 3.2.4.

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

From: Tucker Taft
Sent: Tuesday, December 16, 2013 11:27 AM

> 4.6(57/3) says: ...

> Probably we need something like:
>
>     If a predicate check fails, the effect is as defined in subclause 
> 3.2.4, "Subtype Predicates".

Sounds good to me.

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


Questions? Ask the ACAA Technical Agent