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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada case-statement Date: Thu, 15 Mar 2018 09:37:46 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <365d65ea-5f4b-4b6a-be9b-1bba146394ab@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:50990 Date: 2018-03-15T09:37:46+01:00 List-Id: On 15/03/2018 00:16, Randy Brukardt wrote: > declare > Selector : Day_Type renames Calculate_Day; > subtype Weekend_Subtype is Day_Type range Sat .. Sun; > -- Or use a static predicate if the range is discontiguous. > begin > case Selector is > when Mon .. Fri => > ... > when Sat | Sun => > ... > case Weekend_Subtype'(Selector) is -- A type conversion works, too. > when Sat => > ... > when Sun => > ... > end case; > end case; > end; Ugh, that could be a source quite intractable bugs. If so, I use this pattern time to time then: declare Selector : Day_Type renames Calculate_Day; subtype Weekend_Subtype is Day_Type range Sat .. Sun; begin case Selector is when Mon .. Fri => ... when Weekend_Subtype => ... case Weekend_Subtype'(Selector) is when Sat => ... when Sun => ... end case; end case; And this does not work with when Odd_Week_Day : Mon | Wed | Fri => > Personally, I don't like declarations without explicit subtypes, as the > subtype of an object is critical for understanding the semantics. Not having > the subtype in the source makes it much harder to understand the semantics. Huh, it is definitely true for types, but Ada subtypes are designed for exactly the opposite. On many occasions people here argued that Ada subtype is not a type. Well, from that point of view it must have exactly the same semantics as its base. What's is there to understand more? > Expanding the "id :" notation would definitely harm understandability of Ada > code, and with readability being pretty much the first priority for Ada > syntax, that's a bad thing. I don't see how giving a name could add anything to the semantics. Each alternative exhaustively defines a constraint. No reason to contaminate the name space. > We have been considering making the subtype name in an object renames > optional -- the subtype is a lie anyway (since it is ignored semantically), > and other important properties of the renamed object like "constant" are > omitted. That's about as far as I will go for typeless declarations (and > perhaps even that is too far). Yes, subtype specification in renaming is a noise, and a dangerous one, because it whispers lies as the language does nothing in order to enforce it or at least to check conformance to the constraints stated by it. Certainly, if the present semantics of renaming to stay, the subtype name *must* be removed for the sake of clarity and safety. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de