Dlist and dip1000 challenge

[Steven Schveighoffer]

On 10/23/18 1:18 PM, Nicholas Wilson wrote:
> My hunch (having looked at the source) would be that this is because a 
> "value" to the compiler starts out not scope and must be proved to be 
> scope. In
> 
> tail.next = allocate(stuff.front, tail);
> 
> there is an inductive step the compiler would need to make to infer tail 
> as scope and that goes against the requirement to prove the scopeness of 
> tail (with @safe the goal is to not have false positives, false 
> negatives, like this, are annoying but fine). Please do add a bugziliqa 
> for this even if it proves to be intractable to solve. We can at least 
> document what the compiler can't infer.

Except that there should be no pointers to scope data here -- the only 
thing that is scope really is the string[] pointer. When you extract a 
string from that, it shouldn't be scope.

If it is being inferred scope, how does one have a scope array of 
non-scope pointers?

> I totally agree.
> 
> Plug for https://github.com/dlang/dlang.org/pull/2453
> We really need to better document this stuff.

Well, documentation is good, but if there is a bug or design flaw for 
dip1000 that's what we need to focus on.

Bottom line: I should be able to do what is obviously, trivially @safe 
with dip1000. If I can't do that, then there is something wrong with it.

-Steve