Want reasonable reference counting? Disable automatic sharing of immutable

[H. S. Teoh]

On Sun, Nov 14, 2021 at 10:08:29AM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/14/2021 10:02 AM, Timon Gehr wrote:
> > On 14.11.21 08:16, Walter Bright wrote:
> > > On 11/12/2021 4:31 AM, Steven Schveighoffer wrote:
> > > > One of the prerequisites to doing reference counting is to have
> > > > a mutable piece of data inside an immutable piece of data.
> > > 
> > > Or maybe just give up on having immutable ref counted objects.
> > > Ref counted objects are mutable.
> > 
> > Yes, this is definitely a reasonable way to resolve this debate.
> 
> Sometimes the obvious way is the best way!
> 
> Note that one still can have an immutable *payload* for a ref counted
> object.

This seems to be a reasonable way to resolve this issue.

However, it does have far-reaching implications. For example, it implies
that refcounted objects cannot be used inside any type that may get
passed to a const-receiving interface.

As a hypothetical example, say we have this code:

	class SomePayload { ... }

	struct DataContainer {
		string metadata;
		SomePayload payload;
		SomeOtherPayload payload2;
	}

	void updateData(ref DataContainer data) {
		// presumably update data
	}

	void analyzeData(in DataContainer data) {
		// read-only access of data
	}

	void main() {
		DataContainer data = getData(...);
		updateData(data);
		analyzeData(data);
	}

Using `in` for analyzeData is reasonable, since the function does not
wish to modify the payload.

Now, suppose after some development we decide that we want to make
SomePayload a ref-counted resource instead of a GC-allocated class
instance. So we attempt to modify DataContainer thus:

	struct DataContainer {
		string metadata;
		RefCounted!SomePayload payload;
		SomeOtherPayload payload2;
	}

Now we have a problem: we can no longer call analyzeData with the data,
because it requires mutation of the ref count.

I deliberately nested the refcounted object inside another type, to
illustrate my point: if refcounted objects require mutation (which makes
sense since the ref count needs to be updated), that means *no* function
that might possibly receive a refcounted object (as a nested part of a
larger data structure) will be able to take it as a const argument.

IOW, const becomes unusable with any object that could potentially
contain a ref-counted sub-object.

This is probably not a problem in non-template code, but when you're
dealing with generic code, this will exclude ref-counted objects from
any generic function that uses const in any way. Generic code does not
know (nor care) whether some subobject of an argument might possibly be
refcounted, but it seems reasonable (and likely) that a generic function
that does not plan to modify an argument would use `in` or `const` to
qualify its parameters.  Such a function would not be usable with any
argument that might possibly have ref-counted objects nested somewhere
within it.

So, either (1) we cannot use const/in in generic functions, or (2)
ref-counted objects cannot be used in generic code.

Given D's emphasis on generic code, (1) seems like the only viable
option.  Which makes const in D even narrower in scope than ever.

The same applies for wrapper objects: if any part of the object may
contain a ref-counted object, the entire object becomes unusable with
const.

So, const is turtles all the way down, and ref-counting must be mutable
all the way *up*.


T

-- 
Change is inevitable, except from a vending machine.