!standard 3.10.2(7/2) 11-02-14 AI05-0235-1/02 !reference AI05-0142-4 !class Amendment 10-11-18 !status work item 10-11-18 !status received 10-11-15 !priority Low !difficulty Easy !subject Contradiction in accessibility of explicitly aliased parameters !summary The contradiction is resolved by added "unless otherwise specified" to 3.10.2(7/2). !question The last sentence of 3.10.2(7/2) says "A parameter of a master has the same accessibility level as the master." Besides being vague, this conflicts with the 3.10.2(13.3/3) added by AI05-0142-4: "The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call (which is the same level that the return object ultimately will have)." The level surely cannot be both at the same time. Which is intended? (The second.) !wording Modify the last sentence of 3.10.2(7/2) and add the following AARM notes: {Unless otherwise specified in this International Standard, a}[A] {formal} parameter of [a master] {a callable entity} has the same accessibility level as the master {representing the invocation of the entity}. [Editor's note: Changing to "invocation of the entity" from "(parameter of) a master" has the nasty side-effect of undefining the static accessibility level (since an "invocation" cannot be considered statically). That's why I tried to use "master of the entity", but it clearly doesn't make much sense either.] AARM Ramification: Note that accessibility can differ depending on the view of an object (for both static and dynamic accessibility). This can occur in a number of cases, not just the formal parameter case mentioned here. AARM Reason: We define the (dynamic) accessibility of formal parameters in order that it does not depend on the parameter passing model (by-reference or by-copy) as that is implementation defined. Otherwise, there would be a portability issue. End AARM Notes. !discussion The wording of 3.10.2(7/2) is quite vague. It is clear that it doesn't make sense for this rule to apply to actual parameters, so it is only talking about formal parameters of a callable entity. !ACATS Test [The following is part of the discussion of AI05-0234-1 - Editor.] From: Steve Baird Sent: Monday, November 15, 2010 4:53 PM >... the language is very clear that the dynamic accessibility of such >a parameter is that of the actual object, and we definitely don't want >to have to pass that accessibility with all reference parameters. I'm not disagreeing with you because I see the argument: A dynamic accessibility level is a property of an object (as opposed to a view of an object) and a by-reference parameter doesn't introduce a new object - just a view of an existing object. But how do you reconcile this with 3.10.2(7/2): A parameter of a master has the same accessibility level as the master. ? **************************************************************** From: Randy Brukardt Sent: Monday, November 15, 2010 5:12 PM > But how do you reconcile this with 3.10.2(7/2): > A parameter of a master has the same accessibility level > as the master. > ? I can't, because out of context this doesn't make any sense at all. Masters don't have parameters; a master is a execution or evaluation of something (typically a statement), so I'm not quite sure what this is referring to. In context, it appears to be talking about parameters of declarations, but that doesn't make much sense either with this particular wording. I presume this is intended to do two things: define the *static* accessibility of parameters, and define the *dynamic* accessibility of by-copy parameters, but it is badly botched. Besides the by-reference case, it also is confused with access parameters that have some other accessibility defined (either that of the passed-in entity or "deeper than anything else"). This wording makes no sense for dynamic accessibility (with which it is associated), period. I would prefer to invoke the Duff rule on this one (the ARG is not in the business of answering questions that no one - other than ARG members musing around - has asked). But perhaps there is really something wrong here (not surprising, almost everything about accessibility is screwy in one way or another). **************************************************************** From: Tucker Taft Sent: Monday, November 15, 2010 5:37 PM Dynamic accessibility level *can* vary depending on the "view." Parameters in general are treated like local variables, even when of a type that requires pass by reference. The one exception is explicitly aliased parameters, where they are guaranteed to live at least as long as the return object. Similarly, even if an access discriminant is initialized to designate a global variable, the dynamic accessibility level of a dereference of the access discriminant is (generally) determined by the dynamic accessibility level of the enclosing object. So dynamic accessibility levels do vary according to the view. **************************************************************** From: Randy Brukardt Sent: Monday, November 15, 2010 5:25 PM ... > As far as the "static" check, I'll need Randy to give an example of > what he has in mind there. > I don't see how the value of the tag can possibly affect the static > check. Maybe I'm confused, but in the examples that Steve showed, the accessibility check was against the level of the expression, not the level of the type. That's a check that you cannot make normally at compile-time, as you would fail an accessibility check in normal cases. For example, assuming T is a tagged non-limited type, and TT is an extension of it at the same level: function Fooey (P : in TT; ...) return T'Class is begin if ... then return T'Class(P); -- OK in Ada 95 and Ada 2005 else ... end if; end Fooey; This return statement is legal in Ada 2005. There would be an accessibility check on the tag of TT, but it would staticly be OK. Now further presume that TT has an access discriminant. If we had directly returned the object TT, we would have needed an accessibility check on the object. In that case, the static accessibility check would have failed (we assume that P is local for this purpose). However, if we didn't have that static accessibility check, then we would have to use the accessibility of the actual object, which would have to be passed it (adding overhead). The only reason we don't need that overhead is because we have the static check that fails. Now, in the classwide case, we have *only* a runtime check, because in general we know nothing about the tag until runtime. That means that unless we add some sort of wording about the static check to the dynamic case, we have a distributed overhead in that every reference parameter would have to pass a dynamic accessibility level (in particular, that would be needed for all tagged parameters). Note that the check you described would always pass if Fooey was called with a library-level actual parameter, but should fail if called with a local actual parameter. That's what we have to avoid. **************************************************************** From: Tucker Taft Sent: Monday, November 15, 2010 5:48 PM > Now further presume that TT has an access discriminant. If we had > directly returned the object TT, we would have needed an accessibility > check on the object. In that case, the static accessibility check > would have failed (we assume that P is local for this purpose). > However, if we didn't have that static accessibility check, then we > would have to use the accessibility of the actual object, which would > have to be passed it (adding overhead). The only reason we don't need > that overhead is because we have the static check that fails. The dynamic accessibility level of a parameter, even if passed by reference, is like that of a local variable. Just think what happens when you take 'Access of a tagged parameter in Ada 95 and pass it as an access parameter. It gets a run-time accessibility level that makes it look like a local variable. The new "aliased" parameters are a bit different, in that they promise to live at least as long as the return object, so this example should be fine, even in Ada 2012. > Now, in the classwide case, we have *only* a runtime check, because in > general we know nothing about the tag until runtime. That means that > unless we add some sort of wording about the static check to the > dynamic case, we have a distributed overhead in that every reference > parameter would have to pass a dynamic accessibility level (in > particular, that would be needed for all tagged parameters). Again, the "dynamic" accessibility level of a parameter is "local" even if the actual parameter is a global object. > Note that the check you described would always pass if Fooey was > called with a library-level actual parameter, but should fail if > called with a local actual parameter. That's what we have to avoid. In cases like this, the accessibility level of an access discriminant is the same as the enclosing object, and that is "local" since it is a parameter. That means you don't need to pass anything in, and it will fail the run-time check if the actual object has access discriminants, even if the actual object is a global object. I think the net effect is that the "static" check you were mentioning is *already* a part of the "dynamic" check, since parameters lose their "real" accessibility level and take on the accessibility of a local variable. **************************************************************** From: Randy Brukardt Sent: Monday, November 15, 2010 5:52 PM > Dynamic accessibility level *can* vary depending on the "view." > Parameters in general are treated like local variables, even when of a > type that requires pass by reference. This is an oxymoron. Views are static properties that do not have any effect on dynamic properties. It doesn't make any sense. Beyond that, the one place in the standard that gives some credence to this view is clearly wrong, in that it is contradicted later in the same clause when access parameters are discussed. We never actually decided the question of whether by-reference parameters are objects in their own right, or whether they are just views of the actuals. It appears that we will need to do something on this line (either that, or fix up the wording to make sense). > The one exception is > explicitly aliased parameters, where they are guaranteed to live at > least as long as the return object. > > Similarly, even if an access discriminant is initialized to designate > a global variable, the dynamic accessibility level of a dereference of > the access discriminant is (generally) determined by the dynamic > accessibility level of the enclosing object. The accessibility is that of the access discriminant (which is that of the enclosing object). So what? I don't see your point here. > So dynamic accessibility levels do vary according to the view. Well, that simply doesn't make sense in the Ada model. Of course, nothing else about accessibility makes sense, either, so perhaps we can get away with it. But if that is what we want, it needs to be clearly explained in the AARM, and it is not. Remember that "view of" can automatically be appended to static semantic rules, but not to dynamic rules. If you mean that, you had better say so. Yes, I see these rules are defined in "Static semantics", but that makes no sense for a dynamic value. Accessibility is still badly defined. What else is new. **************************************************************** From: Bob Duff Sent: Monday, November 15, 2010 6:11 PM > > But how do you reconcile this with 3.10.2(7/2): > > A parameter of a master has the same accessibility level > > as the master. > > ? I didn't see the above-quoted message from Steve. Tucker said in another message that dynamic accessibility is a view property. I agree -- it has to be that way, because by-ref and by-copy are (sometimes) impl-def, and we don't want the semantics to differ (other than the essential difference in aliasing). I realize we're talking about tagged types in this conversation, but I'm just saying in general, passing something by ref shouldn't cause differences in accessibility level and so forth. > I can't, because out of context this doesn't make any sense at all. > Masters don't have parameters; a master is a execution or evaluation > of something (typically a statement), so I'm not quite sure what this is > referring to. It's talking about a master that is the execution of a procedure body, and the (formal) parameters of that. These are the plain old run-of-the-mill masters we got from Ada 83 -- all these "little" masters like statements were added since then. **************************************************************** From: Steve Baird Sent: Monday, November 15, 2010 6:31 PM Thanks to Tuck and Bob for straightening that one out. Ignoring new-fangled explicitly aliased parameters, a parameter pretty much behaves like a local with respect to accessibility. In most cases, one is more likely to arrive at the right answer if you go back to the RM and read the relevant wording instead of relying on internalized "I'm sure I remember it works this way" knowledge. In the case of accessibility rules, however, every rereading is an opportunity to get confused all over again. **************************************************************** From: Randy Brukardt Sent: Monday, November 15, 2010 6:35 PM ... > > > But how do you reconcile this with 3.10.2(7/2): > > > A parameter of a master has the same accessibility level > > > as the master. > > > ? > > I didn't see the above-quoted message from Steve. Steve sent it just to me, not sure if that was by accident or on purpose, but since I wanted to get the Tucker and Bob take on it, I replied to the list of names. > Tucker said in another message that dynamic accessibility is a view > property. I agree -- it has to be that way, because by-ref and > by-copy are (sometimes) impl-def, and we don't want the semantics to > differ (other than the essential difference in aliasing). I realize > we're talking about tagged types in this conversation, but I'm just > saying in general, passing something by ref shouldn't cause > differences in accessibility level and so forth. > > > I can't, because out of context this doesn't make any sense at all. > > Masters don't have parameters; a master is a execution or evaluation > > of something (typically a statement), so I'm not quite sure what > > this is referring to. > > It's talking about a master that is the execution of a procedure body, > and the (formal) parameters of that. These are the plain old > run-of-the-mill masters we got from Ada 83 > -- all these "little" masters like statements were added since then. It would be nice if this wording said that. Especially the word "formal", in which case it makes at least some sense. "A {formal} parameter of {the entity that} a master {is executing} has the same accessibility level as the master." Or something like that. Plus we need an exception for access parameters (because this rule surely doesn't not apply to them), and for explicitly aliased parameters. So "{Unless otherwise defined, } a {formal} parameter of {the entity that} a master {is executing} has the same accessibility level as the master." And we also need an AARM note to explain that. "AARM Ramification: Note that accessibility can differ depending on the view of an object (for both static and dynamic accessibility). In addition to the formal parameter case above, similar effects occur for the entities designated by access discriminants." "AARM Reason: We define the (dynamic) accessibility of formal parameters in order that it not depend on the parameter passing model (by-reference or by-copy) as that is implementation defined. Otherwise, there would be a portability issue." Or something like that (not sure we really want to list out examples, there may be more). Since we never actually say "dynamic accessibility in the standard, I put that in parens in the notes. P.S. Note that my original concern probably still exists for explicitly aliased parameters used in an allocator, although I doubt anyone will ever write a test to check that case. ;-) **************************************************************** From: Bob Duff Sent: Monday, November 15, 2010 6:43 PM > Or something like that. Plus we need an exception for access > parameters (because this rule surely doesn't not apply to them), and > for explicitly aliased parameters. So I mostly agree with your message, but I don't see the problem for access parameters. Are you talking about the parameter itself, or what it designates? "X: access T", the accessibility level of X is not relevant, since it's not aliased, so X'[Unchecked_]Access is illegal. The accessibility level of X.all is dynamic, but X.all is not a parameter so the rule we're talking about doesn't apply. The new aliased parameters may well need more thought. **************************************************************** From: Randy Brukardt Sent: Tuesday, November 16, 2010 12:23 AM > > Or something like that. Plus we need an exception for access > > parameters (because this rule surely doesn't not apply to them), and > > for explicitly aliased parameters. So > > I mostly agree with your message, but I don't see the problem for > access parameters. Are you talking about the parameter itself, or > what it designates? "X: access T", the accessibility level of X is > not relevant, since it's not aliased, so X'[Unchecked_]Access is > illegal. The accessibility level of X.all is dynamic, but X.all is > not a parameter so the rule we're talking about doesn't apply. I suppose you are right. > The new aliased parameters may well need more thought. They don't need "more thought", they have their own accessibility rule *(3.10.2(13.3/3)). I wasn't aware of this older blanket rule, or I would have added wording to repeal it in that case. They probably need "more thought" for AI05-0234-1, because I'd expect that the static/dynamic case would come up for allocators (as Tucker points out, they have to pass a return statement). BTW, it seems that we really want formal by-reference parameters to be a new object that happens to share memory with the old object. Besides this accessibility rule (where claiming that dynamic accessibility is a view property is unappealing), we also had similar issues with the values of representation aspects like 'Size and 'Alignment. We surely don't want to have to pass those along with parameters just so we can report them accurately. (I recall we decided that wasn't necessary with some phony hand-waving.) I wouldn't be surprised if this keeps coming up until we finally give in and change the definition... ****************************************************************