Re: Possible GNAT problem with aliased parameters.

[Shark8 <onewingedshark@gmail.com>]

On Friday, October 18, 2013 7:59:58 PM UTC-6, Randy Brukardt wrote:
> Right. To expand on this a bit: an "in" parameter is a constant, of course. 
> "aliased" doesn't change that. If you want to be able to modify the 
> parameter, it has to be an "in out" parameter.

I see. That's not an issue in my little test-project, it's the same underlying idea: Have a node that has some number of other nodes as children. The common usage-case would be reading this sort of graph from a file (Write seldom, read many), which should mean that parameters needn't be modifiable.


> Similarly, "aliased" doesn't change the accessibility rules (with one 
> exception regarding function results), so you still have to use local access 
> types. 

I see that now -- and now I'm trying to figure a way to do it; possibly making the test-module a library-level unit (and thus on-par with the access level of the given package, assuming that it's also library-level, right?

> The primary reason we added it to the language is to allow the 
> "reference" objects to work on containers (like the bounded containers) that 
> directly contain the elements. Of course, we made it general enough that it 
> can be used for other reasons as well.

Right, I was hoping to avoid containers for the time being... and they wouldn't help in this instance, would they?