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 2002:a24:2195:: with SMTP id e143mr3163509ita.18.1553044854927; Tue, 19 Mar 2019 18:20:54 -0700 (PDT) X-Received: by 2002:a9d:7146:: with SMTP id y6mr4106410otj.213.1553044854778; Tue, 19 Mar 2019 18:20:54 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!w126no32012ita.0!news-out.google.com!y88ni65ita.0!nntp.google.com!w126no32008ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 19 Mar 2019 18:20:54 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> <6f9ea847-2903-48c8-9afc-930201f2765a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Intervention needed? From: Jere Injection-Date: Wed, 20 Mar 2019 01:20:54 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:55910 Date: 2019-03-19T18:20:54-07:00 List-Id: On Tuesday, March 19, 2019 at 6:13:20 PM UTC-4, Randy Brukardt wrote: > > The whole point of the Rust scheme as I understand it is to avoid such > things. In particular, you can never have a pointer with multiple owners. > The "borrow" scheme as I understand it allows the owner to be temporarily > transfered (so you can walk lists, for instance), but long-term storage of > such pointers is simply not allowed. You can't build a cursor that way (nor > a doubly-linked list). Perhaps the Rust people have gone beyond simple > borrow semantics -- I don't know. > Rust has a couple levels of ownership and borrowing. It employs both spacial and temporal ownership rules. The 90% solution uses spacial rules (the ones you are most likely familiar with). For managing data across threads or doing complex data types, Rust also provides temporal ownership/borrowing. Think of the same distinction Ada has for named access types vs anonymous access types. You can catch a lot more at compile time with named access types, but anonymous access types can potentially have more runtime checking. In Rust, the standard reference scheme you are probably familiar with employ spacial ownership. If you need temporal ownership, then for single threaded you use things like the RC<> generic (reference counted), and for multi-threaded you use things like the ARC<> generic (atomic reference counted). There are other things of similar nature. These employ temporal rules, which can potentially require runtime checks, though the presence of the spacial ownership rules can help optimize out a lot of the run time checks. I kind of mentioned this above, but the spacial and temporal rules aren't mutually exclusive. They can work together when needed. I don't know if you saw my earlier question to you (from a while back in this email chain), but do you know if Tucker was looking at the recent upgrades to the ownership scheme? Some of them may (or may not) be useful for Ada (if that gets implemented). In particular, in the old ownership scheme, if you needed to use a throwaway variable to capture a return result in Rust, you couldn't reborrow again until that throwaway variable went out of scope. In the updated system, they are able to tell it is throwaway and allow for the ownership transfer. I was thinking about this for Ada particularly since we are required to capture function returns into some sort of variable.