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!feeder.eternal-september.org!aioe.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Your wish list for Ada 202X
Date: Mon, 14 Apr 2014 19:22:56 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <lihu53$kc3$1@loke.gir.dk>
References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com>
 <lifq02$dap$1@loke.gir.dk> <ICL2v.19008$8l4.966@fx29.iad>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: loke.gir.dk 1397521379 20867 69.95.181.76 (15 Apr 2014 00:22:59 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 15 Apr 2014 00:22:59 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:19304
Date: 2014-04-14T19:22:56-05:00
List-Id: <comp.lang.ada>

"Shark8" <OneWingedShark@gmail.com> wrote in message 
news:ICL2v.19008$8l4.966@fx29.iad...
> You can do that already, with explicitly defined subtypes -- consider:
>
> Input : Integer;
>
> -- ...
>
> Case Input of
>   When Integer'First..-1 => -- Handle negative numbers
>   When others =>
>    Case Natural'(Input) is
>     When Natural'First =>   -- Handle 0.
>     When Positive'Range =>  -- Handle positives.
>    end case;
> end case;

Right, but this isn't legal for a variant. So there is an issue for 
variants. The problem is adding an implicit subtype would be very 
incompatible, as it would mean that cases that currently *require* some 
branch would *forbid* them in new code. I suggesting making something like 
the above legal, but it got no traction whatsoever. The alternatives 
proposed are way too complex in my view - they would require a complete redo 
of the way case completeness is handled (both in implementations and to a 
lesser extent in the RM), and the problem just isn't worth that much effort.

                                                    Randy.