Re: Visibility of Indexing aspects

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

On Thursday, August 2, 2018 at 3:31:18 PM UTC-5, Randy Brukardt wrote:
> (Sorry about breaking the thread, the reference headers have gotten too long 
> for the news server to accept them. - RLB)
> 
> "Dan'l Miller" wrote in message
> news:ebf25374-fbd0-4239-9f24-1496b7699f74@googlegroups.com...
> >On Friday, July 27, 2018 at 5:06:00 PM UTC-5, Randy Brukardt wrote:
> >> "Dan'l Miller" wrote in message
> >> news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com...
> >> > ...(even when the programmer considers 4 of them as a bad idea) ...
> >>
> >> A pretty inflexible programmer if you ask me. This is the same sort of
> >> programmer that then complains that the performance of indexing isn't
> >> good
> > enough, because they are triggering all of this expensive mechanism rather
> >> than directly doing something simple.
> >
> >Expensive?  Gee, I would think that precisely the same machine code
> >verbatim
> >would be generated for each of the following syntactic variants of the one
> >and
> >only same semantic meaning:
> >
> >Find (IB,"pear").Data.all := Element'(...); -- Traditional call
> >IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
> >IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5)
> >IB ("pear") := Element'(...); -- Implicit indexing and dereference
> >IB ("pear").Data.all := Element'(...); -- Implicit indexing only
> 
> Surely, and all 5 of these are quite expensive, because the use of Reference
> (which is implicit in all 5 of these!) requires returning (and thus creating
> and destroying) a controlled, composite object. [GNAT has a non-standard way
> of eliminating the controlled part, which of course makes the use of the
> containers substantially less safe.]
> 
> My point is that a programmer that truly cares about performance (and
> hopefully that will only be concerning in a few critical situations) would
> avoid using Reference at all if there isn't a need to update-in-place part
> of the element. That is, one would still use the underlying operations, but
> individually rather than all automatically as part of a set.
> 
>                           Randy.

In the above-mentioned case of prohibiting 4 of the 5, the programmer seeks not performance improvement.  The programmer seeks proscribing the retention of certain* data and structure by the outside-of-this-package world—topics which the outside-of-this-package world has no business retaining or using directly or abusing, syntactic sugar notwithstanding, and historical pre-syntactic-sugar idioms notwithstanding.  The Steelman 3-5B requirement is all about the app-domain designer overtly intentionally proscribing certain* semantics from ever being able to appear in the outside-of-package world.  Steelman 3-5B is not about some clever performance tweaking.

* The certain semantics to be proscribed outside of the declaring package is any form of letting private guts hang out publicly, as some sort of semantic hernia.  {Reference, Reference_Holder, Container_Array} in OP are all intended to be guts internal within the package's private view's abdominal muscle wall, not a semantic hernia gratuitously (mis)placed in the public view of the package.