On Thu, 25 Oct 2018 07:36:48 +0000, Nicholas Wilson wrote:
> We're not even asking for that! github.com/dlang/dlang.org/pull/2453 is mostly the "how do you use this feature, and why is that important", not the nitty gritty. Without the "how to use" and "why" it is impossible to differentiate the wrong nitty gritty from the right nitty gritty (which is what reviewing is).

Huh, I read the bugzilla entry and it seemed moderately clear.

On Thursday, 25 October 2018 at 15:57:14 UTC, Neia Neutuladh wrote:
> On Thu, 25 Oct 2018 07:36:48 +0000, Nicholas Wilson wrote:
>> We're not even asking for that! github.com/dlang/dlang.org/pull/2453 is mostly the "how do you use this feature, and why is that important", not the nitty gritty. Without the "how to use" and "why" it is impossible to differentiate the wrong nitty gritty from the right nitty gritty (which is what reviewing is).
>
> Huh, I read the bugzilla entry and it seemed moderately clear.

That not the point. People will first look at the spec for feature usage, not Bugzilla.

On Thursday, 25 October 2018 at 13:50:15 UTC, Steven Schveighoffer wrote:

> Alarmingly, the current dlist builds fine with dip1000, even though it conceptually is the same thing -- it's just that the casts destroy any tracking of lifetimes (or so my theory goes), so it builds happily. We don't want people to resort to opacity and casts to get around dip1000.

It's the transitivity of `scope` coupled with that other line in the spec that just disables errors in non-@safe code.

Lowering your code, conceptually what's happening is that you're defining this:

struct Storage(T) {
    void add(scope T x);
}

which means you want to escape 'x'.

Now, I understand that that is not the *intent* of your code, but that's what the compiler sees. I'd argue that the "correct" thing to do here is leave the range insertion to some OutputRange algorithm. Unless we can find a way to define tail-`scope` arrays.

On 10/25/2018 6:50 AM, Steven Schveighoffer wrote:
> I know this debate is continuing. But that PR has nothing to do with the problem I'm having (what this post is really about). I'm not returning anything via the first parameter. Just for kicks, I downloaded your PR branch, and it still has the same problem with somehow assuming something is scope. So can you address this problem at all?

The problems people have with DIP1000 nearly always stem from the code being complicated. The code example you posted is quite complicated with a lot of moving parts. The only way to get a handle on what is happening is to break it down into small, and I mean small, chunks.

The trick to finding out why a chunk of code is being inferred as not @safe is to mark it @safe and thereby see where the error is.

Some designs are unworkable with scope without some unsafe casting. A linked list may be one of them (I believe the same holds for linked lists in Rust, but I'm not sure if I remember that correctly).

And lastly, I've done this with Phobos. Phobos is absurdly and ridiculously tangled code with layers and layers and layers of templates that all just forward to yet another template. It makes it pretty hard to track down DIP1000 errors. DIP1000 is not terribly usable when Phobos can't be built with DIP1000, and that requires the PR to make progress on that.

Therefore DIP1000 is pretty dead in the water without the PR.

On Thursday, 25 October 2018 at 15:57:14 UTC, Neia Neutuladh wrote:
> On Thu, 25 Oct 2018 07:36:48 +0000, Nicholas Wilson wrote:
>> We're not even asking for that! github.com/dlang/dlang.org/pull/2453 is mostly the "how do you use this feature, and why is that important", not the nitty gritty. Without the "how to use" and "why" it is impossible to differentiate the wrong nitty gritty from the right nitty gritty (which is what reviewing is).
>
> Huh, I read the bugzilla entry and it seemed moderately clear.


Lolz, one person wants the spec first and the other one wants the code first.

spec: https://github.com/dlang/dlang.org/pull/2453
code: https://github.com/dlang/dmd/pull/8504

Both changes to the spec and changes to the code have been written.
Everybody is holding their ground, never surrender.
It's been going on for 2 months. Hilarious.

On 10/25/18 4:37 PM, Walter Bright wrote:
> On 10/25/2018 6:50 AM, Steven Schveighoffer wrote:
>> I know this debate is continuing. But that PR has nothing to do with the problem I'm having (what this post is really about). I'm not returning anything via the first parameter. Just for kicks, I downloaded your PR branch, and it still has the same problem with somehow assuming something is scope. So can you address this problem at all?
> 
> The problems people have with DIP1000 nearly always stem from the code being complicated. The code example you posted is quite complicated with a lot of moving parts. The only way to get a handle on what is happening is to break it down into small, and I mean small, chunks.
> 
> The trick to finding out why a chunk of code is being inferred as not @safe is to mark it @safe and thereby see where the error is.

I did do that. If you read my story above the rant, I added @safe until I got down to the error.

What I can't figure out is why I'm passing a string to the allocation function, which is allocating a new node on the heap containing the string, but it seems to want to say this should be scope. Both the string and the new node shouldn't be scope.

> Some designs are unworkable with scope without some unsafe casting. A linked list may be one of them (I believe the same holds for linked lists in Rust, but I'm not sure if I remember that correctly).

This sounds really disturbing. But I see things like this: https://rcoh.me/posts/rust-linked-list-basically-impossible/

And it does seem like maybe there simply isn't an easy way to do this. Maybe I do have to carefully figure out the casting and @trusted code, and just go ahead with the overrides. If Rust, with it's far more tested and tried borrow checker can't make this doable without escaping into unsafety, then probably dip1000 isn't going to be able to either.

Still something seems off when I have a type with infinite lifetime (string) and I want to put it into another type with infinite lifetime (Node) and it doesn't allow me to do it, because the strings came in on a scope array. I still feel there is a problem here that may be fundamental to the design of dip1000.

> And lastly, I've done this with Phobos. Phobos is absurdly and ridiculously tangled code with layers and layers and layers of templates that all just forward to yet another template. It makes it pretty hard to track down DIP1000 errors. DIP1000 is not terribly usable when Phobos can't be built with DIP1000, and that requires the PR to make progress on that.
> 
> Therefore DIP1000 is pretty dead in the water without the PR.

If rampant dip1000 cheating is happening like in dlist, then making phobos compile isn't the complete answer IMO. But you are right that until Phobos does compile with dip1000, you pretty much can't figure out anything that uses phobos.

I'm OK with the PR you linked, I just have no idea how to review it, as I'm not a DMD developer. The concept seems specific to Phobos, and a little kludgy, but if it moves things forward, I'd be OK with it. The only thing that seems really strange to me is that `return` is not the return.

-Steve

On Thursday, 25 October 2018 at 21:07:39 UTC, sclytrack wrote:
> On Thursday, 25 October 2018 at 15:57:14 UTC, Neia Neutuladh wrote:
>> On Thu, 25 Oct 2018 07:36:48 +0000, Nicholas Wilson wrote:
>>> We're not even asking for that! github.com/dlang/dlang.org/pull/2453 is mostly the "how do you use this feature, and why is that important", not the nitty gritty. Without the "how to use" and "why" it is impossible to differentiate the wrong nitty gritty from the right nitty gritty (which is what reviewing is).
>>
>> Huh, I read the bugzilla entry and it seemed moderately clear.
>
>
> Lolz, one person wants the spec first and the other one wants the code first.
>
> spec: https://github.com/dlang/dlang.org/pull/2453
> code: https://github.com/dlang/dmd/pull/8504
>
> Both changes to the spec and changes to the code have been written.
> Everybody is holding their ground, never surrender.
> It's been going on for 2 months. Hilarious.

Unfortunately, its not quite that funny: I don't know that the spec PR accurately reflects the code because I didn't write the code. I also don't have the authority to merge either of those PRs, hence the "deadlock" is Walter's to break.

On 10/25/2018 2:12 PM, Steven Schveighoffer wrote:
> What I can't figure out is why I'm passing a string to the allocation function, which is allocating a new node on the heap containing the string, but it seems to want to say this should be scope. Both the string and the new node shouldn't be scope.

Can you boil this down to the minimum?


> If rampant dip1000 cheating is happening like in dlist, then making phobos compile isn't the complete answer IMO.

My intent is for it to work without cheating.


> I'm OK with the PR you linked, I just have no idea how to review it, as I'm not a DMD developer.

One of my ongoing goals is to make DMD easier to understand. Unfortunately, when it does get easy, people then feel comfortable adding complexity until it is no longer understandable. I suspect this is one of those immutable laws like the Peter Principle:

  https://en.wikipedia.org/wiki/Peter_principle

I.e. all software is doomed to be incomprehensible. I'll still struggle against that, though :-) Currently I've been doing some refactoring to replace Visitor traversals with switch statements. I find the latter much simpler to understand, for the simple (!) reason that it has no dependency on an external thing like the Visitor base class.


> The concept seems specific to Phobos, and a little kludgy, but if it moves things forward, I'd be OK with it. The only thing that seems really strange to me is that `return` is not the return.

I tried to make it as narrow as I could (restricted to the first argument) to see if that works well enough. If it does, great. If it doesn't, it can be expanded later, which is much easier than trying to narrow it.

The other thing about it is it is purely additive, so there's no risk of breaking existing code. I.e. it's low risk.

On Thursday, 25 October 2018 at 20:37:55 UTC, Walter Bright wrote:
>
> The problems people have with DIP1000 nearly always stem from the code being complicated. The code example you posted is quite complicated with a lot of moving parts. The only way to get a handle on what is happening is to break it down into small, and I mean small, chunks.

Maybe there is scope for someone to write a tool that lowers all of the complicated features to simpler constructs, complementing existing features like outputting the assembly and AST?

On 10/26/18 6:17 AM, Walter Bright wrote:
> On 10/25/2018 2:12 PM, Steven Schveighoffer wrote:
>> What I can't figure out is why I'm passing a string to the allocation function, which is allocating a new node on the heap containing the string, but it seems to want to say this should be scope. Both the string and the new node shouldn't be scope.
> 
> Can you boil this down to the minimum?

I did: https://run.dlang.io/is/6xDFnr

>> I'm OK with the PR you linked, I just have no idea how to review it, as I'm not a DMD developer.
> 
> One of my ongoing goals is to make DMD easier to understand. Unfortunately, when it does get easy, people then feel comfortable adding complexity until it is no longer understandable. I suspect this is one of those immutable laws like the Peter Principle:
> 
>    https://en.wikipedia.org/wiki/Peter_principle
> 
> I.e. all software is doomed to be incomprehensible. I'll still struggle against that, though :-) Currently I've been doing some refactoring to replace Visitor traversals with switch statements. I find the latter much simpler to understand, for the simple (!) reason that it has no dependency on an external thing like the Visitor base class.

Part of my lack of understanding is my lack of effort to try and understand it. Until then, I really can't say what would make it better or not.

But when sitting next to knowledgable people at dconf this year, it was relatively straightforward to find where I had to change things for my first dmd PR. It's like driving around a strange neighborhood with a local who knows all the back roads.

I need to revisit your talk from 2016.

-Steve