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!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Non_Primitive Operations and Object.Operation Resolution Date: Thu, 21 Apr 2016 14:13:11 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 21 Apr 2016 21:09:54 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="48b46be33beed75863f69afa437f956b"; logging-data="1730"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/nnkqR4fckoCSOJ6BY+/gYOfKxgLm1ppI=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: Cancel-Lock: sha1:8zY5rsylO4NXdbNjzZrblTFbNl0= Xref: news.eternal-september.org comp.lang.ada:30229 Date: 2016-04-21T14:13:11-07:00 List-Id: On 04/21/2016 01:28 PM, Randy Brukardt wrote: > > Humm. I would have agreed with you without looking it up, but that's not > what the wording of 4.1.3 says. It says that "The selector_name shall > resolve to denote a view of a subprogram declared immediately within the > declarative region in which an ancestor of the type T is declared." It then > goes on to make requirements on the first formal parameter of the subprogram > (to be T, AT'Class, access T, or access AT'Class, where AT is some ancestor > of T, [recall that "ancestor of T" includes T itself). T is Digits_Lists.Vector. I don't see any way that Unbounded_Integers.Element could be in the declarative region of that (Digit_Lists) or of any ancestor (such as Ada.Finalization.Controlled). > Your second function Element certainly qualifies on the secondary rules. I > would think that it does *not* qualify on the "declarative region" part of > the rule, but since this isn't your actual code [which is likely to be > subtly different], I can't say that for sure. If the declarative region of > some ancestor type of Digit_Lists includes your second function Element, > then the call should be ambiguous. (The declarative region includes any > bodies, so putting the subprogram in the body doesn't change anything.) What I provided is the actual code, just not /all/ of the actual code. I don't see anything in the full code that would make the pkg body be part of the declarative region of the type or any ancestor. I can provide the full pkg, or you can obtain it from pragmada.x10hosting.com or https://github.com/jrcarter/PragmARC > If you would like, I could take this to the ARG and see if anyone has any > insight. That would probably be a good idea. Subtypes are not types and I'd think should not be considered an ancestor of the type. Considering a subtype as an ancestor seems like it would be a disaster. > In any case, your code is unnecessarily fragile, as even if GNAT is wrong in > this particular instance, future program maintenance could make the GNAT > behavior correct. I'd suggest giving the non-primitive Element a different > name -- less convinient, perhaps, but if you do that you don't have visit > grey areas in the RM. :-) Perhaps. Element seemed the best name at the time, given my limited understanding of the language. -- Jeff Carter "I was either in love, or I had smallpox." Take the Money and Run 137