Editions Ideas

Mike Shah mshah.475 at gmail.com
Tue Jan 6 02:18:11 UTC 2026


On Monday, 5 January 2026 at 10:20:50 UTC, Atila Neves wrote:
> On Monday, 15 December 2025 at 04:20:21 UTC, Mike Shah wrote:
>> On Sunday, 14 December 2025 at 20:16:34 UTC, Walter Bright 
>> wrote:
>>> On 12/14/2025 3:55 AM, jmh530 wrote:
>>>> Lifetimes are as it relates to DIP1000, but the ownership 
>>>> system is probably as important for Rust’s popularity. You 
>>>> tried @live for ownership and I think that’s got much more 
>>>> pushback than DIP1000.
>>>
>>> I deliberately designed the @live feature to not require any 
>>> annotations. And it worked!
>>>
>>> It's still a prototype, though, because nobody wanted it and 
>>> so development came to an end with it.
>>
>> @live is an underrated feature, I'm a fan and it's something 
>> that I occasionally use for its simplicity. Sometimes I toss 
>> @live, @safe, etc. on functions to see that state of my code 
>> to see if the compiler can help me refactor library code.
>
> I don't think anyone should be using features like `@live` 
> themselves and instead the language should provide the features 
> that allow one to write library solutions like smart pointers.

I kind of use @live in what 'Soot' gave me in Java many years ago 
(Soot is a toolkit for writing program analysis for Java). Soot 
allowed you to turn on and off various types of static or dynamic 
analysis based on how much power you needed/wanted/had time for. 
If the compiler provides this to me in an easier way, I am of 
course more happy! I suspect I could rework things with llvm/ldc 
(or gdc) to write a compiler pass to annotate functions with 
@live as needed/temporarily too.

Either way, glad @live is there 🙂


More information about the Digitalmars-d mailing list