`return ref`, DIP25, and struct/class lifetimes

[Joseph Rushton Wakeling via Digitalmars-d-learn]

On Monday, 16 May 2016 at 15:33:09 UTC, Dicebot wrote:
> tl; dr: DIP25 is so heavily under-implemented in its current 
> shape it can be considered 100% broken and experimenting will 
> uncover even more glaring holes.

Well, it's always fun to find the holes in things ... :-)

> To be more precise, judging by experimental observation, 
> currently dip25 only works when there is explicitly a `ref` 
> return value in function or method. Any escaping of reference 
> into a pointer confuses it completely:

To be fair, this is all in line with the DIP25 spec that I 
re-read after running into these issues with my wrapper struct.  
AFAICS pretty much the only case where it really relates to 
structs is when a struct method is returning a reference to an 
internal variable.

It's just frustrating there _isn't_ any thought for the kind of 
wrapper I have in mind, because as you say,

> But there isn't any way to write such wrapper struct without 
> using pointers AFAIK.

As for your point:

> In your actual example putting `return` on `get` method 
> annotation is additionally very misleading because it only 
> implies ensuring result does not outlive struct instance itself 
> - but it gets passed around by value anyway.

I thought much the same, but thought I'd try it on the off chance 
it would make a difference to detection of the problem.

Worst part of all this is that even an invariant to 
assert(this.data !is null) won't protect against issues: the 
pointer doesn't get reset to 0 after the data it points to goes 
out of scope, it just now points to potentially garbage data.

In fact, it's only with compiler optimizations enabled that the 
example I posted even generates the wrong result in its 
`writeln()` call :-P

Basically, it sounds to me like there _is_ no way to guarantee 
the safety/validity of wrapping data via pointer in this way ... 
? :-(