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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.133.88 with SMTP id h85mr2792420iod.90.1513521493512; Sun, 17 Dec 2017 06:38:13 -0800 (PST) X-Received: by 10.157.87.203 with SMTP id q11mr664873oti.8.1513521493379; Sun, 17 Dec 2017 06:38:13 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!g80no585941itg.0!news-out.google.com!b73ni2257ita.0!nntp.google.com!i6no589100itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 17 Dec 2017 06:38:13 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.208.22; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.208.22 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Return by reference From: Jere Injection-Date: Sun, 17 Dec 2017 14:38:13 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:49499 Date: 2017-12-17T06:38:13-08:00 List-Id: Implicit dereference has gone a long way in providing a sort of return by reference capability in Ada. It is still fairly clunky to setup and use though and requires a lot of definitions that aren't always easy to read and discern their purpose without lots of extra comments. Additionally, it still exposes access types in places where a designer may not want to at all. Yes, it does so more safely than before, but I know at least for me, I like to avoid exposing access types as much as possible. I was wondering if Ada could take a step with it further and provide a syntax for return by reference. The building blocks for implementation (Implicit_Dereference based holders) are already in the language now. All that I was curious about was a way to remove the hard to read, clunky setup and a way to remove direct access to the underlying access type. I don't know if I have any good ideas for the syntax honestly. The one idea that I came up with probably has holes: function Stuff(Object : Some_Aliased_Type) return aliased Component_Type; Basically this would expand out to (in the compiler implementation): type Component_Type_Holder(Raw : not null access Component_Type) is limited null record; function Stuff(Object : Some_Aliased_Type) return Component_Type_Holder; as for what could be returned: 1. Any aliased or tagged package level object 2. Any function parameter object (or it's components) provided that the parameter is either explicitly aliased or tagged Local variables to the function would not be allowed as sources so function Stuff(Object : Some_Aliased_Type) return aliased Component_Type is begin return Object.Component; end Stuff; would be ok but: function Stuff(Object : Some_Aliased_Type) return aliased Component_Type is Temp : Some_Aliased_Type; begin return Temp.Component; end Stuff; would not be ok. Calling a return by reference within a function that returns by reference would not be allowed directly, but require an unchecked_access so that they can easily be identified and provide the programmer with opportunity to really consider the source of his/her return value. Again, I'm not necessarily proposing this is the right syntax, I just wanted something to get people thinking. Any syntax/implementation that can improve this functionality is welcome. I'm more interested in hiding the access discriminant and cutting back on all the overly clunky (though currently necessary) declarations that reduce readability. Other thoughts are completely welcome. I know it isn't as easy as I laid out, but I fell like the current implicit_dereference method now gives compiler writers at least a starting tool to take it a step further and enhance readability and safety (less access types exposed).