Re: Interesting effects in array renaming

["Robert I. Eachus" <rieachus@attbi.com>]

Dmitry A. Kazakov wrote:

> I see no link with subtypes. ARM clearly states: 8.5.1(6)
> 
> "... any constraint implied by the subtype_mark of the 
> object_renaming_declaration is ingored)."
> 
> I.e. whatever subtype you, a programmer, might specify I, the compiler, will 
> shamelessly ignore it!
> 
> How safe! Do you really think it is OK? Consider this:

Let me give you a view into the the thinking behind this.  Renaming is 
just another way to create aliasing in Ada.  We couldn't do away with 
the aliasing provided by, for example, subprogram parameters, and all 
aliasing has the potential to create havoc.  The consensus was that Ada 
allows programmers to avoid aliasing, but it doesn't require programmers 
do so.

Why?  Because the havoc that can occur is only in the mind of the 
programmer.  There are a lot of validation tests that use aliasing to 
accomplish a particular purpose.  But the results of all those tests (at 
least in a conforming complier) is predictable.

The same applies in this case.  I often use aliasing "tricks" to make 
writing string handling code easier.  If a subprogam has a parameter say 
S: in String, you don't know that the S'First is 1.  But if you write: 
subtype S_String is String(1..S'Length); My_S: S_String renames S; now 
you can assume that the lower bound is 1.  But notice a detail here.  A 
renaming takes a subtype_mark rather than a subtype_indication.  In 
general when only a subtype mark is allowed in Ada, it indicates that 
what matters is the TYPE indicated by the subtype_mark.

In practice, I tend to write My_S: constant String(1..S'Length) := S; if 
that is what I want, because it also eliminates the possibility that S 
is passed by reference, and some other task modifies it.  But in general 
the question is how much (code and time) can I afford to spend making my 
library routine bulletproof.  Ada allows me to make that sort of 
tradeoff.

Also, it would seem to be a nice idea to either require that the 
constraints implied by subtype_mark in a renaming declaration be 
checked, or that the subtype_mark be a first named subtype.  The first 
doesn't work, because we already know that aliasing is going on. 
Checking the value at one point in time provides no real additional 
safety.  As for requiring the name be a first named subtype, I think 
that was in there at one point.  But it turned out to have problems, 
often the only subtype_mark available to you is an alias!  For example, 
renamings inside generics.  So this turns out to be one of those cases 
where Ada doesn't mandate good sense on the part of the programmer, and 
spends a lot of words covering all the different ways you MAY shoot 
yourself in the foot.

But as long as the semantics are defined, as I said way back at the top, 
the intended effect is the one in the programmers mind.  If that is not 
the required semantic effect, the programmer will be surprised. RM 
8.5.1(6) is pretty clear on what the programmer should expect: "An 
object_renaming_declaration declares a new view of the renamed object..."

If you expect a value conversion, sorry about that, what you get is a 
view conversion.  If you don't understand the difference between a value 
conversion and a view conversion, go reread RM 4.6.