https://github.com/dlang/dmd/pull/10586

It's entirely opt-in by adding the `@live` attribute on a function, and the implementation is pretty much contained in one module, so it doesn't disrupt the rest of the compiler.

On Wednesday, 20 November 2019 at 04:59:37 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/10586
>
> It's entirely opt-in by adding the `@live` attribute on a function, and the implementation is pretty much contained in one module, so it doesn't disrupt the rest of the compiler.

dmd and phobos sure do compile fast! For anyone else:

https://wiki.dlang.org/Starting_as_a_Contributor#Building_from_source

as a bash script:

  mkdir ~/dtest
  cd ~/dtest
  git clone https://github.com/WalterBright/dmd.git
  cd dmd
  git checkout ob
  make -f posix.mak -j8 AUTO_BOOTSTRAP=1
  cd ..
  git clone https://github.com/dlang/phobos
  cd phobos
  make -f posix.mak -j8

and now you can compile with
~/dtest/dmd/generated/linux/release/64/dmd

The longest part of this process is the 'git clone' so why not?

No need to -preview= anything.

@live:  // doesn't add @live to following functions.

I tried writing some bad code and got some nice errors
that made sense. This is the first error that surprises
me (someone who's never learned Rust or dealt with a
borrow checker):

  import std;
  import core.stdc.stdlib: malloc;

  struct Person {
      uint age;
      uint karma;
      char[0] name;
  }

  @live void birthday(Person* p) {
      p.age++;
  } // Error: variable x4.omg.p is left dangling at return

  void main() {
      auto p = cast(Person*)malloc(Person.sizeof + 10);
      birthday(p);
      p.name.ptr[0] = 'B';
      writeln(p);
  }

With linear types in ATS there's a special syntax to
suggest that birthday is giving ownership back to caller
on return. But without that... this of course works:

  @live Person* birthday(Person* p) {
      p.age++;
      return p;
  }
  ...
      p = birthday(p);

On Wednesday, 20 November 2019 at 06:57:55 UTC, mipri wrote:
> With linear types in ATS there's a special syntax to
> suggest that birthday is giving ownership back to caller
> on return. But without that... this of course works:
>
>   @live Person* birthday(Person* p) {
>       p.age++;
>       return p;
>   }
>   ...
>       p = birthday(p);

As does this:

  @live void birthday(scope Person* p) {
      p.age++;
  }

No new syntax needed because it was already present :)

On Wed, Nov 20, 2019 at 3:00 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> https://github.com/dlang/dmd/pull/10586
>
> It's entirely opt-in by adding the `@live` attribute on a function, and the implementation is pretty much contained in one module, so it doesn't disrupt the rest of the compiler.

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.

Are you really certain there's no way to do this without adding yet
more attributes? 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?

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.

> 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.

On Wednesday, 20 November 2019 at 04:59:37 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/10586
>
> It's entirely opt-in by adding the `@live` attribute on a function, and the implementation is pretty much contained in one module, so it doesn't disrupt the rest of the compiler.

It's doubly-linked lists that are supposed to be impossible
without evading the borrow checker, but a linked list seems
to be useful if you just want to provoke it:

---
import std.stdio: write, writeln;
import core.stdc.stdlib: malloc, free;

struct List {
    bool empty;
    List* next;
    int value;

    @live void popFront() {
        empty = next.empty;
        value = next.value;
        next = next.next;
    }
    @live List* front() {
        return &this;
    }
}

@live void dump(scope List* p) {
    if (!p.empty) {
        write(p.value, ' ');
        return dump(p.next);
    } else {
        writeln;
    }
}

@live void free_list(List* p) {
    if (!p.empty) {
        free_list(p.next);
        free(p);
    } else {
        free(p);
    }
}

// three undefined states
void incr(scope List* p) {
    while (!p.empty) {
        p.value++;
        p = p.next;
    }
}

// both Undefined and Owner
void dump_negated(scope List* p) {
    foreach (node; *p) {
        write(-node.value, ' ');
    }
    writeln;
}

// all kinds of errors
List* listOf(int[] args...) {
    List* result = cast(List*)malloc(List.sizeof);
    List* node = result;
    foreach (arg; args) {
        node.empty = false;
        node.value = arg;
        node.next = cast(List*)malloc(List.sizeof);
        node = node.next;
    }
    node.empty = true;
    return result;
}

@live void main() {
    List* a = listOf(1, 2, 3);
    dump(a);
    incr(a);
    dump(a);
    dump_negated(a);
    free_list(a);
    // free_list(a); // undefined state and can't be read
}

On 11/20/2019 12:37 AM, mipri wrote:
> It's doubly-linked lists that are supposed to be impossible
> without evading the borrow checker, but a linked list seems
> to be useful if you just want to provoke it:

I see you're having fun with it :-)

On 20.11.19 05:59, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/10586
> 
> It's entirely opt-in by adding the `@live` attribute on a function, and the implementation is pretty much contained in one module, so it doesn't disrupt the rest of the compiler.

I will look into this in on the weekend, but I think it would help if you could answer the following questions:

- What do you want to achieve with borrowing/ownership in D?

- What can already be done with @live? (Ideally with runnable code examples.)

- How will I write a compiler-checked memory safe program that uses varied allocation strategies, including plain malloc, tracing GC and reference counting?


Right now, the only use I can see for @live is as an incomplete and unsound linting tool in @system code. It doesn't make @safe code any more expressive. To me, added expressiveness in @safe code is the whole point of a borrowing scheme.

On Wednesday, 20 November 2019 at 12:16:29 UTC, Timon Gehr wrote:
> [snip]
>
> Right now, the only use I can see for @live is as an incomplete and unsound linting tool in @system code. It doesn't make @safe code any more expressive. To me, added expressiveness in @safe code is the whole point of a borrowing scheme.

From here [1], Walter says that "OB will also be turned off in @system code." But I don't see anything about @safe or @sysstem in the changelog/ob.md file.

[1] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/

On 21/11/2019 1:16 AM, Timon Gehr wrote:
> Right now, the only use I can see for @live is as an incomplete and unsound linting tool in @system code. It doesn't make @safe code any more expressive. To me, added expressiveness in @safe code is the whole point of a borrowing scheme.

You touch upon a very good point.

I'm starting to think of @live as a superset of @safe. With @trusted being an escape route. If this is the case then perhaps making all pointers non-null (with asserts) would make sense.