[Dlang-internal] DIP1000 discussion and testing

Walter Bright via Dlang-internal dlang-internal at puremagic.com
Sat Oct 22 00:52:02 PDT 2016


On 10/21/2016 8:38 AM, Dicebot wrote:
> 1) DIP1000 has to be changes a lot because it doesn't list most of those
> limitation, leading to natural conclusion that borrowing can be emulated
> as a user code concept. Most importantly, the statement "The design
> utterly relies on a 'ref' value not being returned as a '*'. Any
> attempts to circumvent this will lose the checking" is not mentioned at all.

I believe they are implicit (taking the & of a 'ref' variable has never been 
allowed in @safe code), but they are worth reiterating. It also is apparent now 
that it should explicitly say it has nothing in common with Rust's scheme.


> 2) The whole thing is very disappointing and won't revive dead body of
> @safe as I hoped it will.

What it will do is close the numerous @safe holes that have been identified.


> It won't allow to fix `Unique`, won't enable
> new RNG design Joe has been going, won't allow easy skipping of
> reference count inc/dec - the list goes on.

You're right, scope won't help at all in inc/dec skipping. But all is not lost. 
I have written up a short article on how the compiler can do inc/dec skipping, 
but it'll have to wait until we have an actual RC design.

The idea is to have a memory model that always inserts inc/dec, then allow the 
compiler to remove them as long as it can prove it behaves "as if" the inc/dec 
happened.


> Leaving aside issue 2, I'd like to give a try at updating DIP1000 this
> weekend to be more in match with what you have just explained.

Thank you! Your help is invaluable.



More information about the Dlang-internal mailing list