D Language Foundation May 2024 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole]

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/ninnlmosrxewsrwgrinv@forum.dlang.org

@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.