Challenge: write a reference counted slice that works as much as possible like a built-in slice

[Timon Gehr]

On 12.11.21 02:34, rikki cattermole wrote:
> 
> 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.

This is not an issue at all given an explicit escape hatch.

> - All ``extern(D)`` classes today cannot be in read only memory due the 
> monitor field.

The monitor field should be removed.

> - 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.

`immutable` data should not be implicitly shared.

- We have to define a complete set of allowed equivalence 
transformations based on type qualifiers. This is necessary so that 
there is a specification of what @trusted code may do. It is a 
precondition for any escape hatch like __mutable/__metadata.