@live questions

[Walter Bright]

On 11/21/2020 6:28 PM, Dibyendu Majumdar wrote:
> a) I understand on its own @live is only part of what Rust does? Rust has 
> lifetime annotations and I believe it can track memory allocation across a graph 
> of objects and ensure there is no leak etc.

Rust has an additional capability of specifying which function argument lifetime 
gets attached to the return type, whereas @live just takes the tightest lifetime 
of the supplied arguments. This was discussed a while back, and this extra (and 
optional) specification does not appear to add much value. We can always add it 
later if it turns out to be critical.


> Is my understanding correct that 
> @live only deals with pointers and to compare this to Rust, one has to also 
> include DIP1000?

DIP1000 is intended to be a core feature, not an optional one. It's been around 
long enough and is successful enough to become the default. @live assumes DIP1000.


> My first suggestion is that @live and DIP1000 features should be documented 
> together. I heard in the discussions that DIP1000 is actually not yet documented?

DIP1000 will be for all D code, not just @live.


> b) Is it also the case that DIP1000 is only available if a function is marked 
> @safe?

It's an enhancement for @safe, yes.


> It seems to me that both @live and @safe should be available as compiler flags 
> to turn them on - and not have to rely on annotations. Is this possible? 
 > Certainly in Laser-D I would like these to be ON by default and annotation
 > should be to suppress rather than enable.

My DIP to make @safe the default failed.

Turning @live on by default would be brutal :-)