[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