On Tuesday, 21 August 2018 at 00:09:03 UTC, Walter Bright wrote:
> On 8/20/2018 6:46 AM, Steven Schveighoffer wrote:
>> I would, but I have no idea how dip1000 is supposed to work. I think only you understand it. Even looking at the PR that you have been citing over and over, I can't make heads or tails of what it does or what it allows.
>
> The way to understand dip1000 is to forget about `this`, arrays, structs, classes, delegates, etc. Just think about pointers - functions that take pointers as arguments, and return pointers.
>
> That simplifies things enormously.
>
> Once that makes sense, then deconstruct the higher level constructs into pointers, and then you'll see how they work.
>
> This is why my presentation does it all in terms of pointers:
>
>     http://dconf.org/2017/talks/bright.html
>
> If you're having trouble understanding a particular example, rewrite it in terms of pointers. If it still is inscrutable, then ask about the pointer version here.
>
> (When someone gives me some complex thing and says "I don't understand scope here", I always first rewrite it in terms of pointers. It's the same thing I do with bug reports that use templates - I manually instantiate the templates first.)

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.

Also: destructors? Always `scope`? Sometimes? I just add `scope` when the compiler complains at this point.

I think it's interesting that when I played with Rust I didn't have problems fighting the borrow checker at all. DIP1000 is supposed to have the same safety without the Rust complications but currently Rust is much easier to understand for me.

It doesn't help that the current implementation of -dip1000 doesn't match the document it's supposedly based on.

On 8/21/2018 7:31 AM, 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.

That's what I was saying :-)

The way to deal with this is make a copy of the code, then rewrite it so it does the exact same thing, but with pointers and refs only. No member functions, no delegates, no dynamic arrays. Then it is MUCH MUCH easier to see where the annotations go.


> Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why.
> 
> Also: destructors? Always `scope`? Sometimes? I just add `scope` when the compiler complains at this point.
> 
> I think it's interesting that when I played with Rust I didn't have problems fighting the borrow checker at all. DIP1000 is supposed to have the same safety without the Rust complications but currently Rust is much easier to understand for me.
> 
> It doesn't help that the current implementation of -dip1000 doesn't match the document it's supposedly based on.

All good points. But I cannot make any progress when nobody is willing to pull my PRs that improve the situation.

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

BTW, the annotations do not break things. The worst that will happen is the compiler will complain in @safe code that they are incorrect, and you'll need to fix it or make it @trusted. The compiler is also pretty good about inferring the correct annotations, at least for templates and lambdas, which helps enormously.

However, dip1000 not working with Phobos is a huge impediment to success, and so pulling 8504 is critical.

On Tuesday, 21 August 2018 at 19:36:39 UTC, Walter Bright wrote:
> On 8/21/2018 7:31 AM, 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.
>
> That's what I was saying :-)
>
> The way to deal with this is make a copy of the code, then rewrite it so it does the exact same thing, but with pointers and refs only. No member functions, no delegates, no dynamic arrays. Then it is MUCH MUCH easier to see where the annotations go.


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.


> BTW, the annotations do not break things. The worst that will happen is the compiler will complain in @safe code that they are incorrect, and you'll need to fix it or make it @trusted. The compiler is also pretty good about inferring the correct annotations, at least for templates and lambdas, which helps enormously.

In my opinion, the worst that can happen is I successfully compile my @safe code with -dip1000 and the resulting binary isn't memory-safe, which is what's been happening to me.

> However, dip1000 not working with Phobos is a huge impediment to success, and so pulling 8504 is critical.

I don't have merge rights. I took a look anyway and it mostly looks ok, but I'm not familiar enough with that part of the codebase.

On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote:

> I don't have merge rights. I took a look anyway and it mostly looks ok, but I'm not familiar enough with that part of the codebase.

It's not the implementation that's preventing it from being merged.  It's the idea itself, weak rationale, lack of peer review, lack of consideration for alternatives, and lack of documentation supporting it.  It reeks of "designed on a whim to quickly patch some oversight in the design DIP1000 while trying to get Phobos to compile with -dip1000".

With the proposed idea, order of parameters matters.  We'll need to establish a convention that return parameters must be declared first, which is opposite of https://dlang.org/phobos/std_algorithm_mutation.html#copy. Is that a good idea?  Maybe it is. We haven't vetted the design yet, so I'm not sure.  Why haven't we vetted the design?  Because there currently isn't one; there's just an informal back-of-the-napkin memo uploaded to a bugzilla entry.

The proposed idea wants to make the first parameter, if it's `ref`, special. 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?

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.

Or maybe someone else is willing to just rubber stamp it in the interest of expediency.

Mike

On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote:

> But what bothers me the most...

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

Mike

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

On Tuesday, August 21, 2018 8:18:15 PM MDT Mike Franklin via Digitalmars-d wrote:
> On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote:
> > But what bothers me the most...
>
> 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 judgement 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.

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, but I also do think that DIP 1000 probably should have gone through more peer review. From what I can tell, outside of the simple cases, pretty much everyone has a really hard time understanding it. The situation will likely improve once Phobos properly supports it, and you can more reasonably use it, but the whole thing defnitely seems to be overly complicated given what it's supposed to be doing and what benefits you get from it. Personally, I think that it seems pretty reasonable as long as user-defined types don't get involved, but once they do, it's a mess.

- Jonathan M Davis

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.

Mike

On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote:

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

DIP 1000 is in a bit of limbo at the moment. When I took over the process from Mihails, he told me it was stalled and that the proposal did not match the implementation. So I haven't touched it, which is why it's still marked as Draft. At some point, Walter will revise it to match the implementation and then we'll discuss how to handle it.

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.

On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote:

> It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny.

Sorry, that was poorly stated and conveyed the wrong intent.  It should read:

It is hypocritical an arrogant to believe that only our ideas should require thorough documentation and scrutiny.

Mike