Phobos is now compiled with -preview=dip1000

[Meta]

On Friday, 17 May 2019 at 20:59:43 UTC, Mike Franklin wrote:
> On Friday, 17 May 2019 at 17:03:51 UTC, Meta wrote:
>
>> If you look at `main` above, `rawData` has the same lifetime 
>> as the `dataRange` struct returned from `makeDataRange` and 
>> the queue returned from `copyToQueue`. True, there is some 
>> traditionally unsafe stuff happening in between; however, I 
>> thought that the point of adding all these annotations is to 
>> tell the compiler how the lifetimes of these objects propagate 
>> up and down the call stack, so that it can check that there 
>> will be no memory corruption. I'm not doing anything here that 
>> will result in a pointer to an expired stack frame, or 
>> otherwise cause memory corruption or use after free, or 
>> anything like that (*unless* I allow either `dataRange` or 
>> `result` to escape from the main function - which dip1000 
>> correctly disallows).
>
> I don't think it does because `Queue!(T).store` has infinite 
> lifetime beyond that of even `main`, at least as far as the 
> compiler is concerned.

I see what you're getting at. The compiler sees a slice type 
(i.e., Data[]), knows that it's GC-backed and thus has infinite 
lifetime, and concludes "the data you're trying to put in the 
store has too long of a lifetime". That makes sense, but slices 
don't necessarily have to be backed by the GC, so that seems like 
a faulty heuristic to me and possibly a vector for bugs.

> The compiler doesn't have enough information to know that 
> `store` is tied to the lifetime of `Queue!(T)` (a.k.a 
> `rawData`) and maybe that's a missing language feature.

According to the DIP, "from a lifetime analysis viewpoint, a 
struct is considered a juxtaposition of its direct members." Who 
knows if that's still the case, because Walter has considerably 
changed how it works but has not documented those changes (IIRC, 
I may be wrong on that). That probably means that a Queue!T has 
an infinite lifetime, assuming that the compiler sees its T[] 
member as having an infinite lifetime.

> Maybe we should be allowed to declare aggregate fields as 
> `scope` to convey that, but the compiler currently disallows it.

That might be nice but would also probably cause a dramatic 
increase in complexity. I haven't thought through the possible 
ramifications of making a change like that.