Re: Visibility of Indexing aspects

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote:
> Much ado about nothing.
> 
> The writer of this code erroneously put things in the private part which should have been public. There is a compiler bug leaking from privacy which seduced the writer into thinking that his wrong code is correct.
> 
> The RM is very precise about this, see the references in this thread.
> 
> Love's Labours Lost with any further discussion.

In other words, I made an insightful good point about Ada failing (in that vicinity) to live up to a key portion of its core mission/reason-for-existence from Day One:  the ability to keep private portions of a design private by not forcing public declarations of portions of the design that the designer overtly intends to be kept private.  The response to my insightful good point about Ada embarrassingly failing (in this portion) to live up to one of its fundamental goals (i.e., encapsulation):  Shut it down!  Shut it down!  Speak no more about this topic!  Bury it!  Nothing to see here; move along!
https://www.youtube.com/watch?v=pdFl__NlOpA&frags=pl%2Cwn

This so-called “severe compiler bug” is a highly useful software-engineering usecase of keeping private portions of the design private instead of forcibly dragging source code up to public for no good reason in the design.  The gratuitous publicizing of those OP's private declarations of {Reference, Reference_Holder, Container_Array, ...} opens those gratuitously-publicized declarations up to misuse and abuse by users of the package, in contravention of Steelman requirements 3-5A and 3-5B.

The designer of OP's package wants to evoke the Variable_Indexing for users of the package without permitting the users of the package to directly use/misuse/abuse {Reference, Reference_Holder, Container_Array, ...}.

Steelman 3-5A clearly states “An encapsulation may contain declarations of ••anything•• (including the data elements and operations comprising a type) that is definable in programs.”  Variable_Indexing clearly is a set of operations comprising a type.

Steelman 3-5B clearly states “An encapsulation may be used to inhibit external access to implementation properties of the definition. In particular, it shall be possible to prevent external reference to ••any declaration•• within the encapsulation including automatically defined operations such as type conversions and equality. Definitions that are made within an encapsulation and are ••externally accessible•• may be renamed before use outside the encapsulation.”

So the question is:  how does the _LRM_ live up to Steelman 3-5B's requirement for “•any• declaration” for “automatically defined operations” (e.g., Variable_Indexing) to be made “•externally accessible•” in the public part of the package by being “renamed before use outside” that private part of the package?  It seems that OP's/GNAT's “severe bug” comes far closer to living up to the letter & spirit of Steelman 3-5B's explicit demand there than the current wording of the _LRM_ that seems to force those private declarations of {Reference, Reference_Holder, Container_Array, ...} to be gratuitously publicized.

The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ...} to be public declarations instead of OP's private declarations seems to be itself a crystal-clear “severe noncompliance” with Steelman 3-5A's “•any• declaration … including •automatically defined• operations” intersecting with Steelman 3-5B's “••any declaration•• … including automatically defined operations … made … ••externally accessible•• ”.