```
void foo() {
    int c;

    ....
    int* e;
    e = &c; // Error, lifetime(e's view) is ∞ and is greater than lifetime(c)
}
```

The DIP should make clear that this is wanted for a container library.
Additionally, I miss how this DIP fits in the overall plan of getting rid of the GC. As long as there isn't a written masterplan how to combine those ideas I consider this DIP to be incomplete.

I think this change is not worth it. I believe there is an inherent trade-off for every programming language between usability and theoretically correctness. And IMO this DIP is pushing D way to far in the direction of theoretically correctness. There are far more important things for the adoption of D, like making the frontend a library, shipping with multiple backends.

On 11/08/2016 9:06 PM, Robert burner Schadek wrote:
> ```
> void foo() {
>     int c;
>
>     ....
>     int* e;
>     e = &c; // Error, lifetime(e's view) is ∞ and is greater than
> lifetime(c)
> }
> ```
>
> The DIP should make clear that this is wanted for a container library.
> Additionally, I miss how this DIP fits in the overall plan of getting
> rid of the GC. As long as there isn't a written masterplan how to
> combine those ideas I consider this DIP to be incomplete.
>
> I think this change is not worth it. I believe there is an inherent
> trade-off for every programming language between usability and
> theoretically correctness. And IMO this DIP is pushing D way to far in
> the direction of theoretically correctness. There are far more important
> things for the adoption of D, like making the frontend a library,
> shipping with multiple backends.

I strongly disagree with this.
If you need proof of where it can be used checkout my managed[0] memory concept.

[0] https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d

On Thursday, 11 August 2016 at 09:06:50 UTC, Robert burner Schadek wrote:
> The DIP should make clear that this is wanted for a container library.
> Additionally, I miss how this DIP fits in the overall plan of getting rid of the GC. As long as there isn't a written masterplan how to combine those ideas I consider this DIP to be incomplete.

It's already clear that we need much better escape analysis and guards for safe reference counting.
There isn't any open question that this is the necessary enabler for more RC and less GC.

On 8/11/2016 2:06 AM, Robert burner Schadek wrote:
> The DIP should make clear that this is wanted for a container library.
> Additionally, I miss how this DIP fits in the overall plan of getting rid of the
> GC. As long as there isn't a written masterplan how to combine those ideas I
> consider this DIP to be incomplete.
>
> I think this change is not worth it. I believe there is an inherent trade-off
> for every programming language between usability and theoretically correctness.
> And IMO this DIP is pushing D way to far in the direction of theoretically
> correctness. There are far more important things for the adoption of D, like
> making the frontend a library, shipping with multiple backends.

Without this, we cannot have reference counting that is memory safe.

10 years ago, you'd be right. But these days, with unending cases of expensive exploits using memory safety holes, the world has changed. Programmers are no longer going to accept non-safe languages. Businesses are no longer going to want to pay for security breaches due to pointer bugs. No responsible organization is going to rely on better training to not have security bugs.

D can either get ahead of the curve or be crushed by it.

I've looked for a long time for a scheme that required minimal annotations, not wanting to create a 'bondage and discipline' annotation language. This DIP looks like the best we can do. The 'return ref' feature required very few annotations to be able to safely compile all of Phobos 'ref' code, and this just extends that idea to 'return scope'.

The lack of memory safety is likely what will finally push C into obsolescence. C++ will require such extensive retrofit to make it memory safe that that may seriously blunt its use in new projects.

D absolutely must have memory safety, and ASAP.

On Thursday, 11 August 2016 at 08:29:37 UTC, John Colvin wrote:
> On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
>> Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>
> Can someone talk me through the lifetime algebra for the following?
>
> void foo()
> {
>     int a;
>     int** c;
>     void bar()
>     {
>         int* b = &a;
>         c = &b;
>     }
>     bar();
>     *c; //undefined behaviour
> }
>
> I think it's this:
>
> lifetime(a) = all of foo
> lifetime(c) = infinite (because null) //initially
> lifetime(b) = lifetime(&a) = lifetime(a) = all of foo // ????
> lifetime(c) = lifetime(&b) = lifetime(b) = all of foo //on assignment in bar
>
> That would suggest that dereferencing c was OK, because the lifetime is all of foo. What am I missing?

You are not missing anything. This DIP is flawed because it only handle on indirection level and break down for anything more than this.

On 8/11/2016 3:00 AM, deadalnix wrote:
> This DIP is flawed because it only handle on
> indirection level and break down for anything more than this.

It actually does two levels - the address of the pointer variable ('ref') and the contents of the pointer variable ('scope'). But you are essentially correct. This is not a general annotation system for any pointer in a non-trivial graph of pointers. There is no notion of 'borrowing'.

The question, however, is whether such a system is needed. The intent with this DIP is for people constructing such graphs to make them safe by using reference counted containers for the nodes rather than networks of annotated raw pointers.

This scheme is good enough to prevent the escape of addresses on the stack, and for containers to prevent the escape of pointers to their contents.

On Thursday, 11 August 2016 at 08:29:37 UTC, John Colvin wrote:
> lifetime(a) = all of foo
> lifetime(c) = infinite (because null) //initially
> lifetime(b) = lifetime(&a) = lifetime(a) = all of foo // ????
> lifetime(c) = lifetime(&b) = lifetime(b) = all of foo //on assignment in bar
>
> That would suggest that dereferencing c was OK, because the lifetime is all of foo. What am I missing?

I believe the rule should be lifetime(&e)=visibility(e)&lifetime(e).

On Thursday, 11 August 2016 at 09:45:07 UTC, Martin Nowak wrote:
> It's already clear that we need much better escape analysis and guards for safe reference counting.
> There isn't any open question that this is the necessary enabler for more RC and less GC.

How do you know? Is there a sketch for the planed RC implementation (where can I read it?)

Ok, I disagree, but there is no way that I can proof to be right. You can also not proof that you're right, so I'll trust your judgement.

Can I do this:

```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0

scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```

with the DIP. I could find it.