Re: dip1000 rule 5
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.
Re: dip1000 rule 5
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?
---
Re: dip1000 rule 5
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?
---
Re: dip1000 rule 5
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.
Re: dip1000 rule 5
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.
Re: dip1000 rule 5
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
Re: dip1000 rule 5
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...
