Re: Ada case-statement

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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