!standard 3.7(4) 16-06-06 AC95-00280/00 !class Amendment 16-06-06 !status received no action 16-06-06 !status received 16-04-22 !subject Do subtypes count for determining prefix notation? !summary !appendix From: Randy Brukardt Sent: Friday, April 22, 2016 5:01 PM The following example was posted on comp.lang.ada: package PragmARC.Unbounded_Integers is ... private -- PragmARC.Unbounded_Integers type Calculation_Value is mod System.Max_Binary_Modulus; Digit_Size : constant := Calculation_Value'Size / 2; type Digit_Value is mod 2 ** Digit_Size; package Digit_Lists is new Ada.Containers.Vectors ( Index_Type => Positive, Element_Type => Digit_Value); subtype Digit_List is Digit_Lists.Vector; ... end PragmARC.Unbounded_Integers; package body PragmARC.Unbounded_Integers is ... use type Digit_List; function Element (List : Digit_List; Index : Positive) return Digit_Value; -- If Index is a valid index into List, returns the value stored there; -- otherwise, returns 0 ... ... List.Element (Index) ... -- Index is known to be a valid index for List ... ... Element (Left.Digit, I) ... I may not be a valid index for Left.Digit The questioner says that recent versions of GNAT are reporting the first call as ambiguous, between the function Element declared in the instance Digits_Lists and the function Element declared in the package body. (The second call uses the body version, as it is directly visible as opposed to use-visible.) I've made the obligatory remark about this code being unnecessarily tricky. But it does appear to bring up a question. The important rule is 4.1.3(9.2/3), and the critical sentence is "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." (The rest of the rule makes other requirements and exclusions on the subprogram, none of which change anything in this example.) A declarative region includes the completion, so the spec and body of this package are a single declarative region. Thus, the function Element in the body would be considered if it is immediately within the same declarative region as some ancestor of type Digit_List. However, Digit_List itself is a non-first subtype; the type is declared in the instance Digit_Lists, which clearly is NOT the same declarative region as the function. So, the question is, are non-first subtypes included as "an ancestor of the type T"? The definition of ancestor of a type in 3.4.1(10/2) only talks about types, so I would think that non-first subtypes would not be involved. Moreover, my recall of the reason for 4.1.3(9.2/3) is that we wanted primitives and class-wide routines to be included; subprograms declared with (only) a non-first subtype are not primitive. But the wording seems vague enough that one might come to some other interpretation. So far as I can tell, none of the 4.1.3 ACATS tests are requiring this behavior -- but it's always possible that some test not related to prefix notation is unintentionally requiring it. So, is this GNAT behavior wrong? (Both from a language lawyer perspective and from what we actually want.) *************************************************************** From: Bob Duff Sent: Friday, April 22, 2016 6:17 PM > The following example was posted on comp.lang.ada: Why are we picking up misc stuff from comp.lang.ada? > So, the question is, are non-first subtypes included as "an ancestor > of the type T"? Subtypes are not included. Type mismatch: Is_Ancestor expects a "type", but was passed a "subtype". ;-) > The definition of ancestor of a type in 3.4.1(10/2) only talks about > types, so I would think that non-first subtypes would not be involved. Correct. "Ancestor" is a relationship between types. Subtypes (first or not) are irrelevant. >... Moreover, my > recall of the reason for 4.1.3(9.2/3) is that we wanted primitives and >class-wide routines to be included; subprograms declared with (only) a >non-first subtype are not primitive. But the wording seems vague enough >that one might come to some other interpretation. > > So far as I can tell, none of the 4.1.3 ACATS tests are requiring this > behavior -- but it's always possible that some test not related to > prefix notation is unintentionally requiring it. > > So, is this GNAT behavior wrong? (Both from a language lawyer > perspective Yes. > and from what we actually want.) Don't know. The GNAT behavior seems better than the RM-required behavior, at least on one example. I see no language bug here, so no need for ARG involvement. And AdaCore doesn't cull bug reports from comp.lang.ada. Feel free to encourage whoever asked the question to submit a proper bug report. *************************************************************** From: Randy Brukardt Sent: Friday, April 22, 2016 7:26 PM > Why are we picking up misc stuff from comp.lang.ada? We aren't. I promised the questioner I'd ask, because I wasn't sure. And in particular, I wasn't sure what the rule *should* be, as opposed to what it literally says. ... > > So, is this GNAT behavior wrong? (Both from a language lawyer > > perspective > > Yes. > > > and from what we actually want.) > > Don't know. The GNAT behavior seems better than the RM-required > behavior, at least on one example. > > I see no language bug here, so no need for ARG involvement. > And AdaCore doesn't cull bug reports from comp.lang.ada. > Feel free to encourage whoever asked the question to submit a proper > bug report. Did two different Bobs write the above two paragraphs? :-) If the GNAT behavior is "better" than the required behavior, then that certainly is a language issue that justifies discussion here. Certainly, there should be an ACATS test to verify whatever we decide (if people are running into it, it should be tested, and it seems like a common mistake for an implementer) -- I definitely don't feel comfortable just writing such a test if indeed it would ban something valuable. The original questioner was asking on comp.lang.ada before deciding whether to submit a bug report; I presume that he will do that now. In any case, GNAT itself is not my concern here, my concern is whether we got the language wrong for some reason. And whether an ACATS test would be a problem. *************************************************************** From: Tucker Taft Sent: Saturday, April 23, 2016 9:48 AM The place where a (non-first) *subtype* is declared is always irrelevant to the visibility of operations. It is only where a type is declared that matters. Changing this would be a bit of an earthquake, in my view. ***************************************************************