Prototype of Ownership/Borrowing System for D

[Manu]

On Wed, Nov 20, 2019 at 6:20 PM Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 11/19/2019 11:49 PM, Manu wrote:
> > I haven't read thoroughly yet, although I have been following along
> > the way and understand the goals... but I really can't not say
> > straight up that I think `@live` is very upsetting to me.
> > I hate to bike-shed, but at face value `@live` is a very unintuitive
> > name. It offers me no intuition what to expect, and I have at no point
> > along this process has any idea what it means or why you chose that
> > word, and I think that's an immediate ref flag.
>
> The "live" refers to the data flow analysis which discovers which pointers are
> "live" or "dead" at any point in the flow graph. This is critical for what O/B
> is trying to do.
>
> `@ownerBorrow` just seems a little awkward :-)
>
> Andrei proposed `@live`, and I like it. It's short, sweet, and sounds good.
>
> > Are you really certain there's no way to do this without adding yet
> > more attributes?
>
> We'll never be able to compile C-like code if we force an O/B system on all the
> code. There has to be a way to distinguish, like what `pure` does. D would be
> unusable if everything had to be `pure`. My understanding of O/B is you're going
> to have to redesign code and data structures to use it effectively. I.e. it'll
> break everything. Rust has a powerful enough marketing machine to convince
> people that redesigning your programs is a Good Thing (tm) and perhaps it is,
> but we don't have the muscle to do that.

Is there a path perhaps where you only attribute parameters instead of
the whole function? We already have `scope`, `return`, etc on
parameters... ?

> > It would be better if an attribute was not required
> > for this... we're already way overloaded in that department.
> > Timon appeared to have a competing proposal which didn't add an
> > attribute. I never saw your critique of his work, how do your relative
> > approaches compare?
>
> I don't have a good understanding of Timon's work yet.

Okay. I'd like to see a rigorous comparison somewhere with the key
differences called out.