On 2021-11-08 22:43, Paul Backus wrote:
> On Tuesday, 9 November 2021 at 01:14:24 UTC, tsbockman wrote:
>> Borrowing is required for a general-purpose RC type, so that the payload can actually be used without a reference to the payload escaping outside the lifetime of the counting reference. But, the effective lifetime of the counting reference is not visible to the `scope` borrow checker, because at any point the reference's destructor may be manually called, potentially `free`ing the payload while there is still an extant borrowed reference.
>>
>> With current language semantics, the destructor (and any other similar operations, such as reassignment) of the reference type must be `@system` to prevent misuse of the destructor in `@safe` code.
>>     https://issues.dlang.org/show_bug.cgi?id=21981
>>
>> The solution to this problem is to introduce some way of telling the compiler, "this destructor is `@safe` to call automatically at the end of the object's scope, but `@system` to call early or manually."
> 
> I believe it is also possible to make this `@safe` by doing borrow checking at runtime, although it would introduce some overhead, and make the API less ergonomic.
> 
> Maybe the best compromise we can reach in the current language is to offer a `@safe` borrow-checked interface alongside an unchecked `@system` interface.

This is interesting. Maybe you could add a little detail to the bug report or to this thread?

On 2021-11-09 0:30, H. S. Teoh wrote:
> On Mon, Nov 08, 2021 at 10:38:59PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 11/8/21 8:04 PM, deadalnix wrote:
>>> On Monday, 8 November 2021 at 22:40:03 UTC, Andrei Alexandrescu wrote:
>>>> On 2021-11-08 17:26, rikki cattermole wrote:
>>>>> a reference counted struct should never be const
>>>>
>>>> So then we're toast. If that's the case we're looking at the most
>>>> important challenge to the D language right now.
>>>
>>> Not necessarily, but this is in fact the same problem as the head
>>> mutable problem.
>>>
>>> If `const RCSlice!(const T)` can convert to `RCSlice!(const T)`,
>>> which it should to have the same semantic as slice.
>>>
>>> The reference counting problem goes away if you can mutate the head.
>>
>> The reference count cannot be in the head, it has to be in the block.
>> So this conversion is actually unsound.
> [...]
> 
> It could work if the block has a mutable counter at the top and the rest
> is immutable/const.  But the current type system cannot express such a
> thing; if the head is const, then it's const all the way down.

The mutable counter can be at a negative address that is not accessible to the "normal" type system. There's nothing wrong with having a piece of mutable data next to a piece of immutable data.

I think that we just came to an agreement that the metadata stuff should be handled separately potentially using different memory.

I suggested this as an escape hatch with my custom reference type back in my second comment!

https://forum.dlang.org/post/smc9r2$7nh$1@digitalmars.com

I think I have summarized the main points that has been brought up in this thread. If I have forgotten something please add.

- ``const``/``immutable`` memory can be in read only memory, attempting to modify this will result in the termination of a program.
- All ``extern(D)`` classes today cannot be in read only memory due the monitor field.
- Both ``const`` and ``immutable`` today provide guarantees that what memory is pointed to is readable. But it may not be writable and therefore cannot be written to.
- Any escape hatch must acknowledge that memory lifetimes is not the same thing as the memory containing data of a given type.
- For a value reference type, with the outer type being ``const`` is equivalent to just the template argument type being ``const``. ``struct Type(const T)`` is equivalent to ``const(Type!T)`` and ``const(Type!(const(T)))``.
- Runtime checks are required for if the metadata or data storage is null.
- Atomic operations are expensive, to lesson this the compiler should elide calls to reference counting methods with the help of something like ARC and scope.

On Friday, 12 November 2021 at 01:34:05 UTC, rikki cattermole wrote:
> - Any escape hatch must acknowledge that memory lifetimes is not the same thing as the memory containing data of a given type.

I'm sorry, can you expound on this one a little more?  I don't follow.

On 12/11/2021 2:49 PM, Greg Strong wrote:
> On Friday, 12 November 2021 at 01:34:05 UTC, rikki cattermole wrote:
>> - Any escape hatch must acknowledge that memory lifetimes is not the same thing as the memory containing data of a given type.
> 
> I'm sorry, can you expound on this one a little more?  I don't follow.

So the reference count needs to be heap allocated.
The value of a given type must be heap allocated as well.

These two memory addresses need not be next to each other.

I.e.

struct ReferenceCount {
	shared(int) count;
}

struct Node(Type) {
	Type value;
}

struct Reference(Type) {
	private {
		Node* data;
		ReferenceCount* refCount;
	}
}

Rather than:

struct Reference(Type) {
	private	Storage!type* storage;
}

struct Storage(Type) {
	Type value;
	shared(int) refCount;
}

The idea is that the value may be in read only memory, but the reference cannot be due to requirement of mutation.