On 29/08/2024 2:49 AM, Mike Shah wrote:
On Wednesday, 28 August 2024 at 13:53:47 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 29/08/2024 12:55 AM, Mike Shah wrote:
On Wednesday, 28 August 2024 at 09:04:58 UTC, Anonymouse wrote:
[...]
Thanks for the write-up Mike!
I do like @live, curious others thoughts? Perhaps it doesn't need to
be an attribute though and is instead a compiler flag for an analysis
pass on any function (kind of reminds me of frameworks like Soot for
Java that you control various analysis passes). Perhaps a
conversation for another thread 🙂
Word of warning on @live, for owner escape analysis to function, you
must have escape analysis. It uses DIP1000 for "escape analysis".
The only issue with this is, what I realized recently is that DIP1000
isn't escape analysis, its owner escape analysis for stack memory.
These two analysis's are completely opposite in what they offer in
terms of guarantees.
Interesting -- I'll have to look more into this. I'll read along the
other threads otherwise on DIP 1000 to keep the discussion there. Thanks!
Here is an example from Paul where DIP1000 is not designed to model:
https://forum.dlang.org/post/[email protected]
@live is naturally going to fall apart for anything related to function
calls (ignoring the fact that its opt-in).
Borrow checkers need to be able to differentiate between a parameter
being an output and/or input. Otherwise they can't protect you.
Note: that is in the woes thread so its restricted on replies.
