!standard 4.6(57/3) 14-02-12 AI05-0096-1/01 !class binding interpretation 14-02-12 !status work item 14-02-12 !status received 13-12-16 !priority Low !difficulty Easy !qualifier Omission !subject The exception raised by a subtype conversion with a failed 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.) !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. ****************************************************************