Dlist and dip1000 challenge

[Steven Schveighoffer]

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