There are 4 rules listed.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md




What is rule 5?


int* global_ptr;

void abc() {
    scope int* a;
    int* b;
    scope int* c = a;      // Error, rule 5
    scope int* d = b;      // Ok
    int* i = a;            // Ok, scope is inferred for i
    global_ptr = d;        // Error, lifetime(d) < lifetime(global_ptr)
    global_ptr = i;        // Error, lifetime(i) < lifetime(global_ptr)
    int* j;
    global_ptr = j;        // Ok, j is not scope
}


Also it says scope inferred for i
int * i = a;

So inferred, does that mean?

scope int *i = a;


It looks very similar to the error rule 5.

    scope int* c = a;      // Error, rule 5


When DIP1000 is in and copy constructors, then the language is more or less finished?

Wouldn't you call it D3 because of the name mangling of DIP1000 once activated
by default?

On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
> There are 4 rules listed.
> ...
> What is rule 5?
> ...
> Wouldn't you call it D3 because of the name mangling of DIP1000 once activated by default?

That "rule 5" looks like a straight up mistake. As for D3... IMHO, no, not by a long shot. There's 1014 and 1016, 1008, there's `shared`, there are improved move-assignments, there's `__mutable` and `@__future`, there are tons of issues in Bugzilla, the standard library is long overdue for a huge look-over...

On Sunday, 25 November 2018 at 19:49:03 UTC, Stanislav Blinov wrote:
> On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
>> There are 4 rules listed.
>> ...
>> What is rule 5?
>> ...
>> Wouldn't you call it D3 because of the name mangling of DIP1000 once activated by default?
>
> That "rule 5" looks like a straight up mistake. As for D3... IMHO, no, not by a long shot. There's 1014 and 1016, 1008, there's `shared`, there are improved move-assignments, there's `__mutable` and `@__future`, there are tons of issues in Bugzilla, the standard library is long overdue for a huge look-over...


Did DIP1000 go through any review process? I'm seeing it is a draft.


https://github.com/dlang/DIPs/blob/master/PROCEDURE.md

Keeps talking about a Drafts subdirectory. I don't see any directory named
"Drafts".


I only see

accepted
archived //old stuff
rejected

On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote:

> Did DIP1000 go through any review process? I'm seeing it is a draft.

Review links are at the very end.

> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md
>
> Keeps talking about a Drafts subdirectory. I don't see any directory named "Drafts".

Not sure about that one. Maybe Mike Parker could elaborate on this.

On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote:
>
>
> Did DIP1000 go through any review process? I'm seeing it is a draft.

The previous DIP manager marked DIPs as Draft while they were under review. I don't use that anymore. I left DIP1000 untouched after I took over, however. Walter told me he'll revise it at some point to reflect the actual implementation.


>
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md
>
> Keeps talking about a Drafts subdirectory. I don't see any directory named
> "Drafts".
>

It was originally my intention to push new DIPs into a Drafts subdirectory for the Draft Review stage, but it's more convenient to handle it in the pull request thread. I never edited the document to reflect that and didn't notice it when I've looked it over. Now that you've pointed it out, I'll revise it.

On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
> There are 4 rules listed.
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>
>
>
>
> What is rule 5?
>
>
> int* global_ptr;
>
> void abc() {
>     scope int* a;
>     int* b;
>     scope int* c = a;      // Error, rule 5
>     scope int* d = b;      // Ok
>     int* i = a;            // Ok, scope is inferred for i
>     global_ptr = d;        // Error, lifetime(d) < lifetime(global_ptr)
>     global_ptr = i;        // Error, lifetime(i) < lifetime(global_ptr)
>     int* j;
>     global_ptr = j;        // Ok, j is not scope
> }
>

---

Are the following assumptions correct?


lifetime(a) < lifetime(b)
Means that b is older and lives longer than a. Or better, the data that b is pointing
to is older and lives longer than the one that a is pointing too. With the exception
of the null pointer which gets unlimited lifetime because it does not corrupt memory.

---

scope int * a;

The variable gets unlimited lifetime because the value it is pointing is assigned
null. And that throws exception when trying to access the memory and because
it does not corrupt memory it is assigned unlimited lifetime. Also once a variable
is assigned unlimited lifetime, then it retains that unlimited lifetime during
the entire reachability of the variable.

scope int * c = a;

The above is allowed. You are assigning a variable that according to the compiler
has unlimited lifetime. Therefore the variable c will be handled like it has
unlimited lifetime by the compiler.
lifetime(c) <= lifetime(a)
The dip talks about longer and shorter, but is equal okay too?

int * c = a;

The above can not be inferred because scope is only inferred when it is assigned
a limited lifetime. So it is an error.

---
How is a person able to understand this DIP?
---

How many DIP manager are there?
When is a DIP assigned a number?

---

On Monday, 26 November 2018 at 09:10:23 UTC, sclytrack wrote:
> On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
>> There are 4 rules listed.
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>>
>>
>>
>>
>> What is rule 5?
>>
>>
>> int* global_ptr;
>>
>> void abc() {
>>     scope int* a;
>>     int* b;
>>     scope int* c = a;      // Error, rule 5
>>     scope int* d = b;      // Ok
>>     int* i = a;            // Ok, scope is inferred for i
>>     global_ptr = d;        // Error, lifetime(d) < lifetime(global_ptr)
>>     global_ptr = i;        // Error, lifetime(i) < lifetime(global_ptr)
>>     int* j;
>>     global_ptr = j;        // Ok, j is not scope
>> }
>>
>
> ---
>
> Are the following assumptions correct?
>
>
> lifetime(a) < lifetime(b)
> Means that b is older and lives longer than a. Or better, the data that b is pointing
> to is older and lives longer than the one that a is pointing too. With the exception
> of the null pointer which gets unlimited lifetime because it does not corrupt memory.
>
> ---
>
> scope int * a;
>
> The variable gets unlimited lifetime because the value it is pointing is assigned
> null. And that throws exception when trying to access the memory and because
> it does not corrupt memory it is assigned unlimited lifetime. Also once a variable
> is assigned unlimited lifetime, then it retains that unlimited lifetime during
> the entire reachability of the variable.
>
> scope int * c = a;

works

>
> The above is allowed. You are assigning a variable that according to the compiler
> has unlimited lifetime. Therefore the variable c will be handled like it has
> unlimited lifetime by the compiler.
> lifetime(c) <= lifetime(a)
> The dip talks about longer and shorter, but is equal okay too?
>
> int * c = a;

works (compiles without error and is inferred scope)

>
> The above can not be inferred because scope is only inferred when it is assigned
> a limited lifetime. So it is an error.

Rule number 2 of the DIP1000 between quotes

"2. A variable is inferred to be scope if it is initialized with a value that has a non-∞ lifetime."

I made an error here. Once scope always scope. And will infer scope as much as
possible. Rule two is more for local variables that haven't even been marked
with scope. A pointer to them needs to be inferred scope.


>
> ---
> How is a person able to understand this DIP?


./dmd -betterC -dip1000 test.d

> ---
>
> How many DIP manager are there?

I'll assume single person.

> When is a DIP assigned a number?
>
> ---

On Tuesday, 27 November 2018 at 08:56:47 UTC, sclytrack wrote:

>> ---
>> How is a person able to understand this DIP?
>
>
> ./dmd -betterC -dip1000 test.d

I'll repeat: the DIP does not currently match the implementation. I was not involved in any of it and have no idea what the diff actually is. Walter informed me a while back that he will update the DIP to match the implementation at some point. I'll discuss it with him after the new year and see where we are.

>
>> ---
>>
>> How many DIP manager are there?
>
> I'll assume single person.

Yep, just me.

>
>> When is a DIP assigned a number?
>>
>> ---

As soon as I merge the PR. That's the point where it moves from Draft Review to the first round of Community Review (and I will update the procedures doc to reflect that). Which DIPs get merged when depends on a number of factors -- what is the state of each DIP, what's the priority, how many are currently under review in the post-Draft stages, is the author available to move forward, etc.