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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: I am not understanding user defined exceptions
Date: Wed, 8 Feb 2017 17:37:04 -0600
Organization: JSA Research & Innovation
Message-ID: <o7ga31$6a9$1@franka.jacob-sparre.dk>
References: <6cb6e781-c6df-4962-99e3-760e7c7fab88@googlegroups.com>
 <k3ba9chta4hqdcv4q6npmrdbffsnfeoi8l@4ax.com> <o73tvs$je$1@dont-email.me>
 <lyshntg9yh.fsf@pushface.org> <o7fm37$4ir$1@dont-email.me>
NNTP-Posting-Host: rrsoftware.com
X-Trace: franka.jacob-sparre.dk 1486597025 6473 24.196.82.226 (8 Feb 2017
 23:37:05 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 8 Feb 2017 23:37:05 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:33275
Date: 2017-02-08T17:37:04-06:00
List-Id: <comp.lang.ada>

Simon Wright <simon@pushface.org> wrote:
> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> subtype Exclude_One is integer with static_predicate Exclude_One /= 1;
>
> My version with Dynamic_Predicate works, but (having checked with John
> Barnes' book) I see I was being too cautious.
>
> Having read over that, I have to say that the GNAT approach (just
> Predicate, the compiler knows which one to choose) seems the right one
> to me!

The GNAT approach causes a very significant maintenance hazard: if you 
depend on the static properties of a predicate, a seemingly innocous change 
can break a lot of code. (And that code may not even be yours, if the 
predicate is in a specification of a shared library. Imagine someone 
changing a predicate in the specifications of GDKAda that changes it from 
static to dynamic; a lot of other people's code would break and they'd have 
no understanding of why (or any hope of fixing it). By declaring your intent 
as static or dynamic, clients can properly use the predicate subtype and you 
as the maintainer can't break their expectations without at least realizing 
that there is a potential problem.

This is especially true as many expressions that *seem* simple aren't 
allowed as static predicates (simple math operators aren't allowed, for 
instance). After all, a static predicate is a (bizarre) way to describe a 
set constraint, whereas a dynamic predicate is an implicitly inserted 
assertion. Quite different semantically.

                                       Randy.