On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote:

> Whatever the status of DIP 1000, I would point out that that one of Walter's DIPs is in Community Review right now after sitting in the PR queue in Draft Review for a while. Once this review stage is done, it will go back into the queue to await Final Review like any other DIP. The only difference between this and other DIPs is that there will be no Formal Assessment for it. And this is the second DIP from Walter that has gone through the process since I've come on board, with DIP 1008 being put on pause at his request.

I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table".  There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc...

Yet I and others have to go through the DIP process for much less significant changes to the language, and rightly so:

https://github.com/dlang/dmd/pull/7310
https://github.com/dlang/dmd/pull/7079

All I want to see from Walter is:
1) a sufficiently documented proposal for his idea
2) an RFC from the community
3) a PR to the spec documenting the final design

I don't think that's too much to ask.

Mike

On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote:

> I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table".  There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc...

A 3rd example (https://github.com/dlang/dmd/pull/8346) to throw a little more salt on the wound.  The DIP25/1000 rabbit hole is deepening behind the curtain.

Mike

On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote:
> Something else that rubs me the wrong way is that DIP 1000 is currently in a status of `DRAFT`:  https://github.com/dlang/DIPs/blob/master/DIPs/README.md
>
> What the heck is going on here?  We're adding features to the compiler and modifying Phobos in production releases based on a `DRAFT` proposal?
>
> Furthermore, I find it hypocritical that some of us are put through a disproportionately burdensome DIP process requiring thorough documentation, multiple peer reviews, excessive delays, and judgment that defaults to "no" for some of the most minute changes to the language, but a game-changing feature like DIP 1000 can just be amended on a whim.

+1,
For valuable contributors like you, it's far from friendly.
Friendly atmosphere increases creativity.
Although, for an industrial-level language, it should be careful to add many features (A core engine that can simulate a lot of easy to use sugars is important, for those potential hackers. )

On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote:
> On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis wrote:
>
>> The reality of the matter is that the DIP system is a formal way to propose language changes in order to convince Walter and Andrei that those changes should be implemented, whereas if Walter or Andrei writes the DIP, they're already convinced. This isn't a democracy. Walter is the BDFL, and it's his call. So, I really don't think that it's hypocritical
>
> Walter and Andrei need to have their ideas vetted by the community, not in an effort to convince anyone, but for quality assurance, to ensure they're not overlooking something.
>
> It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny.
>
The formal DIP process was put in place after DIP1000. I would even daresay that the process was put in place because of the issue with DIP1000 (the rigorously checked DIP's are all >1000 for that reason).

On Wednesday, 22 August 2018 at 03:58:42 UTC, Nicholas Wilson wrote:
> On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
>> The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function.
>>
>> Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why.
>
> The way I think about it is if you have a function that takes a pointer, any pointer, and either returns it or a pointer derived from it (dereferencing or indexing) that argument must be marked `return`. In your case it was a pointer derived from `this` so `return` must be applied to `this`.

I guess my problem is that DIP1000 talks about returning scope values and they don't seem to actually exist in the implementation.

On 8/21/2018 2:17 PM, Atila Neves wrote:
> Well, no. The syntax isn't the same for member functions. The examples from the actual DIP don't compile. There it says:
> 
> -------
> scope can be applied to function return values (even though it is not a type qualifier). It must be applied to the left of the declaration, in the same way ref is:
> 
> scope int* foo();     // applies to return value
> --------
> 
> Except:
> 
> -------
> struct MyStruct { scope int* foo() scope; }
> 
> foo.d(1): Error: redundant attribute scope
> -------
> Meaning the first `scope` actually applies to `this`. Writing this out as a non-member function won't help me declare member functions!
> 
> I still don't know how to return a ref/pointer that's scoped. And I thought I'd written code that did that. Maybe I did. I'm very confused.

Here's how you make it work:

---
@safe:

struct MyStruct {
    ref int foo() return;
    int* bar() return;
}

ref int sun() {
    MyStruct s;
    return s.foo(); // returning s.foo() escapes a reference to local variable s
}

int* moon() {
    MyStruct s;
    return s.bar(); // returning s.bar() escapes a reference to local variable s
}
---
In effect, the 'return' on 'foo()' says:

    The return value of foo() contains the address of 'this', and if the return escapes the scope of what 'this' is a ref to, then it's an error.

On 8/21/2018 8:58 PM, Nicholas Wilson wrote:
> On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
>> The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function.
>>
>> Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why.
> 
> The way I think about it is if you have a function that takes a pointer, any pointer, and either returns it or a pointer derived from it (dereferencing or indexing) that argument must be marked `return`. In your case it was a pointer derived from `this` so `return` must be applied to `this`.


Another way to think about it is this:

   S s;
   return &s;

We all know that is an error. The idea is to have a way to express that for:

    S s;
    return s.foo();

and:

    S s;
    return foo(&s);

so that the compiler knows that the return value of foo() is attached to the lifetime of s. Pretty much everything flows from that.

On 8/21/2018 6:07 PM, Mike Franklin wrote:
> The proposed idea wants to make the first parameter, if it's `ref`, special.

This is because Phobos is written with functions of the form:

    void put(sink, parameters...)

which corresponds to:

    sink.put(parameters...)

The two forms are fairly interchangeable, made more so by the Uniform Function Call Syntax.

> Why not the first `ref` parameter regardless of whether it's the absolute first in the list.  Why not the last `ref` parameter?  Why not all `ref` parameters?

Good question. If this fairly restricted form solves the problems, then there is no need for the more flexible form. Things can always be made more flexible in the future, but tightening things can be pretty disruptive. Hence, unless there is an obvious and fairly strong case case for the flexibility, then it should be avoided for now.


> But what bothers me the most is I think it's missing the bigger picture:  D needs a way to annotate lifetimes.  Maybe `scope` and `return` with weird conditions based on the order of parameters and their attributes are the way to go.  Maybe there's another way that hasn't yet been considered.
> 
> Put together a thorough description of the proposal, justify it, ask the larger community for comment, vet it, and document it. At least that's what it's going to take to get me to take action on the PR.

dip1000 has been around for two years, and its predecessor dip25 several years now. Plenty of time for anyone to comment and/or propose something better.

---

I want to ensure Atila is successful with this. But that means Phobos has to compile with dip1000. So I need to make it work.

On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:

>> The proposed idea wants to make the first parameter, if it's `ref`, special.
>
> This is because Phobos is written with functions of the form:
>
>     void put(sink, parameters...)
>
> which corresponds to:
>
>     sink.put(parameters...)
>
> The two forms are fairly interchangeable, made more so by the Uniform Function Call Syntax.

Makes perfect sense. This is the kind of stuff I'd like you to put in a formal document and present to us as an RFC along with your PR.  Then transfer that information to the spec to accompany the DMD PR, after you've received feedback.

Mike

On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:

> I want to ensure Atila is successful with this. But that means Phobos has to compile with dip1000. So I need to make it work.

There's a good chance you'll get your PR merged when it's documented and vetted, then you'll be able to make it work for Atila.  The only think holding it up is you.

I'm not asking for much.  Sufficiently document the idea, open it up for comment and Q & A, transfer the documentation to the spec to accompany the DMD implementation PR.

Assuming there's no major flaws in the design, it should get merged.

Mike

P.S. Actually, I've been trying to document it myself, since you don't seem willing to, but it's going to take me a lot longer to figure out what's in your head than it would take you.