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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,af3dada69080e420 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-23 19:35:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc01.POSTED!not-for-mail Message-ID: <3EF7B8CC.3000100@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Interesting effects in array renaming References: <3EF5E6B8.3030203@spam.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc01 1056422101 24.62.164.137 (Tue, 24 Jun 2003 02:35:01 GMT) NNTP-Posting-Date: Tue, 24 Jun 2003 02:35:01 GMT Organization: AT&T Broadband Date: Tue, 24 Jun 2003 02:35:01 GMT Xref: archiver1.google.com comp.lang.ada:39631 Date: 2003-06-24T02:35:01+00:00 List-Id: 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.