www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's the difference between DIP25 and DIP1000?

reply Emmanuelle <VuLXn6DBW PPtUm7TvV6nsw.com> writes:
Hi, I've been reading about DIP25 and DIP1000 and I'm not quite 
sure if I understand the difference between the two—is DIP1000 
supposed to be a rework of DIP25? And what's the difference 
between `return ref` and `return scope`? Also, will there be any 
compiler version where `-preview=dip25` and/or `-preview=dip1000` 
are the default?

Thanks!
Jun 18 2019
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, June 18, 2019 8:53:31 AM MDT Emmanuelle via Digitalmars-d-learn 
wrote:

 Hi, I've been reading about DIP25 and DIP1000 and I'm not quite
 sure if I understand the difference between the two—is DIP1000
 supposed to be a rework of DIP25? And what's the difference
 between `return ref` and `return scope`? Also, will there be any
 compiler version where `-preview=dip25` and/or `-preview=dip1000`
 are the default?

 Thanks!


DIP 25 only has to do with making returning ref safe. The basic problem is
something like

ref int foo()
{
    int i;
    return bar(i);
}

ref int bar(ref int i)
{
    return i;
}

When foo returns, it ends up returning a ref to a local variable that then
doesn't exist. That's caught with simpler code such as

ref int foo()
{
    int i;
    return i;
}

but by passing it to a function like bar, the compiler can no longer see
that what's being returned is a ref of a local variable. And what bar is
doing would be perfectly legitimate if it were given something other than a
local variable or if foo didn't return bar's result. So, DIP 25 was
introduced to fix the problem.

Basically, what DIP 25 does is require that any function that accepts a ref
and returns that same ref needs to have the ref parameter marked with
return. That way, when the compiler is compiling a function like foo, it can
see whether bar is returning a ref to the ref parameter or not and thus
whether it's safe to return the result of bar from foo. DIP 25 only deals
with this one issue and has no effect on the type system. It just allows the
compiler to detect whether a function returns a ref parameter.

DIP 1000, on the other hand, actually affects the type system. When scope is
put on a variable, it's actually part of its type, and scope variables are
not allowed to have any references to them escape, meaning that once
something is scope, it can pretty much only be passed to something else that
takes it as scope. That can apply to ref parameters, but it can also apply
to pointers, class references, dynamic arrays, etc. So, it's much more
general than what DIP 25 is trying to do. Something like

ref int* foo()
{
    auto ptr = new int(42);
    return bar(ptr);
}

ref int* bar(return ref int* ptr)
{
    return ptr;
}

int* baz = foo();

would be perfectly legal with DIP 25, whereas with DIP 1000, something like

scope ref int* foo()
{
    auto ptr = new int(42);
    return bar(ptr);
}

scope ref int* bar(return scope ref int* ptr)
{
    return ptr;
}

int* baz = foo();

wouldn't be. Unfortunately, actually understanding all of the ins and outs
of DIP 1000 is pretty complicated, and I haven't spent enough time with it,
so I probably can't explain it well enough. But it covers a _lot_ more than
DIP 25, and IIRC, DIP 1000 depends on DIP 25.

As for when either of them will become the default? I have no clue. -dip25
has been around for years and AFAIK gets used very little, whereas -dip1000
is quite new. Historically, we've done a poor job of switching to new
behavior like this when it breaks existing code, and the change usually
simply doesn't happen. IIRC, Walter intends to try to make it so that code
compiled with -dip1000 and code compiled without it are compatible (so that
people can actually start using -dip1000 and still have their code interact
with code that doesn't use it) and work towards making -dip1000 the default
behavior, but I wouldn't expect such a change to happen soon. However,
Walter is behind this strongly enough that I expect that it will
_eventually_ become the default behavior.

- Jonathan M Davis
Jun 18 2019
parent Emmanuelle <VuLXn6DBW PPtUm7TvV6nsw.com> writes:
On Tuesday, 18 June 2019 at 21:57:32 UTC, Jonathan M Davis wrote:

 -snip-


Thank you, it's clear to me now :)
Jun 18 2019