!standard 4.8(2) 08-07-07 AI05-0104-1/02 !class binding interpretation 08-06-15 !status ARG Approved 7-0-1 08-06-21 !status work item 08-06-15 !status received 06-04-30 !priority Low !difficulty Easy !qualifier Omission !subject Null exclusions are not allowed in uninitialized allocators !summary The subtype_indication of an uninitialized allocator cannot have a null_exclusion. !question Ptr := new not null Some_Ptr; appears to be legal (because "not null" is part of a subtype_indication), but it will always raise Constraint_Error. However, Ptr := new not null Some_Ptr'(Some_Func); is syntactically illegal, because "not null" is not allowed on a subtype_mark. It seems unusual that the useless case is allowed, and the useful case is not allowed. It would seem that either both should be disallowed or both allowed. !wording Add after 4.8(2): For an allocator with a subtype_indication, the subtype_indication shall not specify a null_exclusion. !discussion An uninitialized allocator with a null_exclusion would necessarily raise Constraint_Error (because the default initialization is null). Moreover, an initialized allocator cannot have a null_exclusion, as they are not included in the syntax of a qualified expression. So it is better to prevent this oddity in the first place. !corrigendum 4.8(2) @dinsa @xcode<@fa@ft<@b>@fa< subtype_indication | >@ft<@b>@fa< qualified_expression>> @dinst @xindent with a @fa, the @fa shall not specify a @fa.> !ACATS Test An ACATS B-Test should be created to check that this is illegal. (Probably just add cases to the existing tests.) !appendix From: Randy Brukardt Sent: Wednesday, April 30, 2008 10:55 PM I just noticed the following: Ptr := new not null Some_Ptr; is legal (because "not null" is part of a subtype_indication), but it will always raise Constraint_Error. (The version of GNAT I've been using reports this as illegal, but I can't find any rule that makes that true.) OTOH, Ptr := new not null Some_Ptr'(Some_Func); is syntactically illegal, because "not null" is not allowed on a subtype_mark. You'd have to write instead: subtype Not_Null_Some_Ptr is not null Some_Ptr; ... Ptr := new Not_Null_Some_Ptr'(Some_Func); I know we tried hard to avoid cases like this, but we seem to have left one. It seems too goofy to allow "not null" on qualified expressions in general, so to fix this we'd either have to allow "not null" specifically in front of a qualified expression in an allocator, or make the initial case illegal (since it can't possibly be useful). I think I'd probably lean toward the latter, although consistency would suggest the former. Should we do anything about this, or just file it in the oddities file? And if we should do something, what? **************************************************************** From: Robert Dewar Sent: Thursday, May 1, 2008 5:26 AM > Should we do anything about this, or just file it in the oddities > file? And if we should do something, what? Either file in the oddities file, or make the first case illegal, since it is obviously junk. **************************************************************** From: Tucker Taft Sent: Thursday, May 1, 2008 8:24 AM It seems a harmless oddity, but if we don't want it, I would disallow it via a syntactic rule in 4.8: After 4.8(2): For an allocator with a subtype_indication, the subtype_indication shall not specify a null_exclusion. The hope is that the above wording does not prevent nested null_exclusions, appearing, say, in expressions used within a constraint. ****************************************************************