Phobos is now compiled with -preview=dip1000
jared771 at gmail.com
Fri May 17 21:57:51 UTC 2019
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.
More information about the Digitalmars-d-announce