From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:3c0e:: with SMTP id k14-v6mr1455741iob.105.1532640317741; Thu, 26 Jul 2018 14:25:17 -0700 (PDT) X-Received: by 2002:aca:de07:: with SMTP id v7-v6mr92979oig.5.1532640317538; Thu, 26 Jul 2018 14:25:17 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!d7-v6no1158745itj.0!news-out.google.com!k71-v6ni1226itk.0!nntp.google.com!d7-v6no1158744itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 26 Jul 2018 14:25:17 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <40d568da-4715-42de-8e28-98da39a5c974@googlegroups.com> <34f499f7-020f-4dcc-adad-0ab1113386d1@googlegroups.com> <9d69e7b5-6b2d-4607-9f7b-affa78c41620@googlegroups.com> <41c711cb-0300-4a41-93d3-e69297ae1945@googlegroups.com> <42de4aa3-9e7c-44b8-aa84-712cc7ce03c6@googlegroups.com> <9b6b6f10-5956-4a19-83f5-c1c015c62602@googlegroups.com> <8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com> <756cb66b-1ef8-4d9e-b679-118b6c59e89c@googlegroups.com> <1392b483-af72-4dbe-ad51-bd703405b7a8@googlegroups.com> <3eebe2fb-f066-4248-9b2f-1db32497fd82@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com> Subject: Re: Visibility of Indexing aspects From: "Dan'l Miller" Injection-Date: Thu, 26 Jul 2018 21:25:17 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 6321 X-Received-Body-CRC: 3891750251 Xref: reader02.eternal-september.org comp.lang.ada:53973 Date: 2018-07-26T14:25:17-07:00 List-Id: On Thursday, July 26, 2018 at 3:31:04 PM UTC-5, Shark8 wrote: > On Wednesday, July 25, 2018 at 6:12:24 PM UTC-6, Randy Brukardt wrote: > > "Dan'l Miller" wrote in message=20 > > news:googlegroups.com... > > 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 w= hich > > >> should have been public. There is a compiler bug leaking from privac= y > > >>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 ... > >=20 > > Sounds like babble to me. What's used by the client has to be public,= =20 > > period. >=20 > But this is legal: >=20 > Package K is > Type Example is private; > Private > Type Example is null record; > For Example'Size use 4; > End K; >=20 > Package J is > Type Hex is range 16#0#..16#F# > with Size =3D> 4; > =20 > Type Ex_2 is record > Item_1 : Hex; > Item_2 : K.Example; > end record > with Size =3D> 8; >=20 > End J; >=20 > > ... > > >The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, = ...}=20 > > >to be public declarations ... > >=20 > > ...is perfectly fine -- there's nothing wrong or dangerous with using t= hem=20 > > directly. Indeed, "indexing" is just a shorthand for a longer call invo= lving=20 > > Reference -- you're always allowed to make the longer call, just like y= ou=20 > > are allowed to put in .all even if you could have omitted it. We went t= o=20 > > substantial lengths to ensure that you can't keep a reference value lon= ger=20 > > than the existence of the return object from Reference -- regardless of= how=20 > > you use the package. (Telling people not to do something is never an=20 > > effective technique for safety!) >=20 > But that's not the issue that is being cited in the original post. > The issue is that all the indexing-attributes are declared/used in the pr= ivate part and are [apparently] > being used in the publicly visible part. >=20 > Is this correct? Yes that is correct regarding the OP, but my replies were requesting what t= he wonderful Ada vision for the alternative to this so-called =E2=80=9Cseve= re bug=E2=80=9D are. So far the only wonderful Ada vision for a better wor= ld than the =E2=80=9Csevere bug=E2=80=9D is to chain-migrate =E2=80=A2all= =E2=80=A2 the intended-to-be-private declarations of =E2=80=A2all=E2=80=A2 = of {Variable_Indexing, Reference, Refence_Holder, Container_Array, =E2=80= =A6} gratuitously up to a polluted public view to satisfy the gratuitous ov= er-achievement requirement of _AARM_:2016's =C2=B622/3 of =C2=A74.1.6 on pa= ge 189 so that the same semantics shall be able to written in 5 different w= ays (when the programmer overtly considered 4 of the 5 a bad idea), which i= s a worse vomit of intended-to-be-private declarations into public than wha= t the so-called =E2=80=9Csevere bug=E2=80=9D divulged: Find (IB,"pear").Data.all :=3D Element'(...); -- Traditional call IB.Find ("pear").Data.all :=3D Element'(...); -- Call of prefixed view IB.Find ("pear") :=3D Element'(...); -- Implicit dereference (see 4.1.5) IB ("pear") :=3D Element'(...); -- Implicit indexing and dereference IB ("pear").Data.all :=3D Element'(...); -- Implicit indexing only Apparently in subsequent replies the justifications for this gratuitous ove= r-achievement requirement of mandating 5 different syntaxes of writing the = same semantics (even when the programmer considers 4 of them as a bad idea)= is: 1) (perceived?) effort reduction by compiler writers and 2) syntactic-sugar features get a green-lighted free pass but software-engi= neering principles (e.g., Steelman requirement 3-5B) get prioritized lower,= or worse, perhaps are viewed as governing Ada83-only in the dustbin of his= tory.