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