newshound2 at digitalmars.com
Sun Nov 22 07:22:22 UTC 2020
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
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 :-)
More information about the Digitalmars-d