On Friday, 10 April 2015 at 09:16:38 UTC, ixid wrote:
>> http://wiki.dlang.org/DIP77
>
> We seem to be incrementally edging towards Rust's memory management system or something similar and retracing their steps along the path to get there. Hypothetically how close could we get to being able to opt into a Rust world from the GC world or C worlds of memory management?

extern(Rust) embraceExtendExtinguish();

On Friday, 10 April 2015 at 09:15:11 UTC, Walter Bright wrote:
> ref2 is copied.

You cannot copy a resource like a memfile. It is already closed and the memory is gone.

On 4/10/2015 2:27 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 10 April 2015 at 09:15:11 UTC, Walter Bright wrote:
>> ref2 is copied.
>
> You cannot copy a resource like a memfile. It is already closed and the memory
> is gone.

Please read the DIP again. The copy happens earlier.

On 4/10/2015 2:16 AM, ixid wrote:
>> http://wiki.dlang.org/DIP77
>
> We seem to be incrementally edging towards Rust's memory management system or
> something similar and retracing their steps along the path to get there.
> Hypothetically how close could we get to being able to opt into a Rust world
> from the GC world or C worlds of memory management?

As I explained to deadalnix in this thread, D's semantics in this regard are a superset of Rust's.

On Friday, 10 April 2015 at 09:28:57 UTC, Walter Bright wrote:
> Please read the DIP again. The copy happens earlier.

But one cannot keep a stateful resource alive by copying memory. One would have to take ownership to keep it alive. In order to do that you need a model for ownership.

On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP77

So someone passes an RCO via ref to avoid the inc/dec, and because that imposes safety issues we turn it into some sort of pass by value under the hood, defeating the purpose, and provide an opt-out via @system opAssign.

Wouldn't it more straightforward to make pass-by-ref unsafe (@system) for RCOs?

Then the only thing missing to make this equally powerful, would be an optimization opportunity for the compiler to elide copies of pass-by-value RCOs, e.g. it could avoid calling the postblit when the function retains the refcount.

On Thursday, 9 April 2015 at 12:05:16 UTC, Michel Fortin wrote:
> """
> An object is assumed to be reference counted if it has a postblit and a destructor, and does not have an opAssign marked @system.
> """

It seems to only fit to RCO, I'm not positive though.
We should formalize this, by documenting it and by adding isRCO traits to phobos.

On 4/10/2015 2:54 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 10 April 2015 at 09:28:57 UTC, Walter Bright wrote:
>> Please read the DIP again. The copy happens earlier.
>
> But one cannot keep a stateful resource alive by copying memory. One would have
> to take ownership to keep it alive. In order to do that you need a model for
> ownership.

That's what ref counting is about.

On 4/10/2015 3:02 AM, Martin Nowak wrote:
> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP77
>
> So someone passes an RCO via ref to avoid the inc/dec, and because that imposes
> safety issues we turn it into some sort of pass by value under the hood,
> defeating the purpose, and provide an opt-out via @system opAssign.

Or you could pass it by const ref (which is what Rust essentially does).


> Wouldn't it more straightforward to make pass-by-ref unsafe (@system) for RCOs?

That's what we have now. It's not good enough.

On 2015-04-09 18:43:25 +0000, Walter Bright <newshound2@digitalmars.com> said:

> The only real purpose to a postblit is to support ref counting. Why would a by-value container use a postblit and not ref count?

Because reference counting has tradoffs, or because someone translates an exiting C++ program and want to keep the semantics the same to make the translation simpler. If you want to limit postblit to the reference counting use case I guess that's fine, although this limitation should probably be clarified somewhere because to someone with a C++ background it looks a lot like a substitute for a copy-constructor.

But this goes beyond containers. Destructors and postblits are implicitly created whenever a field contained within a struct has them. So you could have this:

	struct Big
	{
		RCArray!T array;
		int[1000] ints;
	}

and now implicit copies of Big are made because Big implicitly gained a destructor and postblit from its array field. But at least you gain memory safety.

...or maybe not. Let's add another field to Big:

	struct Handle
	{
		// shouldn't be able to make copies of this
		@disable this(this) {}
	}

	struct Big
	{
		RCArray!T array;
		int[1000] ints;
		Handle handle;
	}

Now Big's implicit postblit becomes disabled too (because Handle can't handle copying), therefore it is no longer a RCO object and the compiler will no longer create temporary copies. Now you've trashed memory-safety.

To be fair, my opPin idea suffers a similar fate here: there is no opPin defined for Big, which creates a hole in memory-safety. To compensate, the compiler would have to call opPin individually for each field that defines it.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca