Tell us your DIP1000 woes

[Richard (Rikki) Andrew Cattermole]

I'll include the items I said at the meeting just so we can hopefully 
minimize extras.

 From meeting:

- Reference counted types (not in language) get affected by scope, like 
any other pointer contained struct. Which is a problem since it has 
runtime lifetime, not a CT analyzed one.
- Only one output is described, (returned value or this pointer), this 
means ref and out parameters aren't outputs and therefore cannot be @safe.
- The abomination that is scope return + return scope (this is easier to 
resolve in terms of new UDA's, but does not solve communicability of 
behavior).

Other ones:

- It does not model owners and borrows, this isn't in its scope, it also 
means in practice it has to try and act as a guarantee both up the call 
stack and down it, which is not what such escape analysis is designed 
for. Which makes it a lot harder to use.
- Does not attempt at modelling globals including TLS, so with @safe 
code you can absolutely escape memory from the thread completely 
unintentionally.

As someone who has over 120k LOC fully annotated DIP1000 code, my only 
conclusion is that DIP1000 has some serious scope of proposal level 
issues and cannot be rectified. This has been my conclusion *after* 
trying to fix it for a few years and having no proposals that could.

Depending upon how DConf goes, I might be looking at dumping it, because 
as-is it has too many scope-level holes that will not be fixed. But in 
saying that, Dennis I sincerely hope you can do some serious magic here 
because it'll be impressive!