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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,203d1f2317947ef5
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: others clause
Date: 1996/08/31
Message-ID: <Dx03FL.C8w@world.std.com>#1/1
X-Deja-AN: 177626571
references: <INFO-ADA%96082914113458@LISTSERV.NODAK.EDU>
 <3227AAA6.67C9@ghgcorp.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-08-31T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3227AAA6.67C9@ghgcorp.com>,
Mike Bishop  <mbishop@ghgcorp.com> wrote:
>Chris Sparks wrote:
>>     when others => null;               --WHY ISN'T THIS ERRONEOUS?

I think Chris means "illegal", not "erroneous".  Ada doesn't use
"erroneous" in its normal English sense.

>fact, using others is a good idea even when all values are explicitly
>covered. If you add more values to the type but forget to modify the
>case statement, you can still handle the new values in the others
>choice.

Yeah, at least in *some* cases, you want to have the empty others case,
in case you add new values later.  In other cases, though, you *want* to
get a compile-time error, so you can analyze the newly added cases -- in
those cases, don't put "others".

Another reason for allowing seemingly-empty others clauses is to handle
out-of-range values.  Consider, for example:

   T2: Integer := Integer'Last;

   case T2 + 1 is
     when Integer'First .. -1 => null;
     when 0                   => null;
     when 1 .. Integer'Last   => null;
     when others              => null;
   end case;

T2+1 might overflow, raising Constraint_Error.  Or, it might produce a
value outside the range of Integer, and thus jump to the others case.
Similarly, the variable being testing might have an uninitialized value
outside the range of the type (although that's unlikely for Integer).
Note that these cases are not erroneous -- we have tried to minimize the
possibility of wild jumps in Ada 95.  Here's a slightly more realistic
example:

    type My_Int is range -2**15..2**15-1;
    
    X, Y: My_Int := ...;
    
    case X+Y is
       when -2**15..-1 => ...;
       when 0..2**15-1 => ...;
       when others => ...;
    end case;

In this case, 5.4(9) requires each value in My_Int'Base to be covered.
But that range is implementation defined!  We don't want the legality of
that "others" to depend on whether the compiler happened to choose a
16-bit or 32-bit machine type to represent My_Int'Base.

>Not only is others not erroneous here, it is required. If the type of
>the case expression is root_integer or universal_integer, you must have
>an others choice.

No, the case expression was of type Integer, not root_integer or
universal_integer -- no others required.

- Bob