From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Type_Invariant and Finalize
Date: Thu, 17 Jul 2014 18:15:26 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnlsg4lu.i0l.lithiumcat@nat.rebma.instinctive.eu>
Injection-Date: Thu, 17 Jul 2014 18:15:26 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
	logging-data="31444"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+7N5WkveN8Lry163Sl5T44"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:4hn5M34POWS/nu4sigHPGvbHzQo=
Xref: news.eternal-september.org comp.lang.ada:21009
Date: 2014-07-17T18:15:26+00:00
List-Id: <comp.lang.ada>

Hello,

I have been trying out the new contrat-oriented aspects on Ada 2012, and
wondered how Type_Invariant interacts with user-defined finalization.

I have several types for which a Type_Invariant makes sense (and is
often already mostly implemented the old-fashionned way, with pragma
Assert at the end of subprograms), except after the first call to
Finalize.

The latest example is a sorted array of non-null
paccess-to-indefinite-type values, where the "sortedness" is a natural
type inveriant, but in Finalize I release the memory using an instance
of Unchecked_Deallocation.

I'm already a bit uneasy with not having "not null except after
Finalize" access types, but in the example above after the first call to
Finalize I get an array of either null or invalid access values, and the
natural type invariant can't be computed.

Searching through the ARM, I can't see any special treatment of the
Finalize procedure with regard to Type_Invariant aspect, so presumably
the type inveriant is also checked at the end of Finalize.

Have I missed something that allows Finalize to make an object not fit
the type invariant?

Or should I prepare for it, e.g. with an explicit boolean record
component that is False for the most of the lifetime of the object,
until the first call to Finalize?


Thanks in advance for your insights,
Natasha