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

[H. S. Teoh]

On Thu, Nov 11, 2021 at 06:17:53PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2021-11-08 20:14, tsbockman wrote:
[...]
> > **Either** the reference count is part of the target of the RC
> > type's internal indirection, in which case it can be mutated in
> > `pure` code, but is frozen by an outer, transitive `immutable`,
> > **or** the reference count is conceptualized as an entry in a
> > separate global data structure which can be located by using the
> > address of the payload as a key, meaning that incrementing it does
> > not mutate the target, but is im`pure`.
> 
> Yah, my thoughts exactly. My money is on the latter option. The
> reference counter is metadata, not data, and should not be treated as
> part of the data even though implementation-wise it is.
> 
> Eduard and I stopped short of being able to formalize this.

This sounds like it's a good idea.  But how would that interact with
`pure`?  Will it be just part of life that RC types are necessarily
impure?


[...]
> > What you seem to be asking for instead is a way to trick the type
> > system into agreeing that mutating a reference count doesn't
> > actually mutate anything, which is nonsense. If that's really
> > necessary for some reason, it needs to be special cased into the
> > language spec, like how `pure` explicitly permits memory allocation.
> 
> It's not nonsense. Or if it is a lot other things can be categorized
> as nonsense, such as the GC recycling memory of one type and
> presenting it as a different type etc.

As I said elsewhere, it's a different level of abstraction. The GC
operates at a lower level of abstraction, and therefore does "dirty"
things like casting to/from immutable, pointer arithmetic, etc.. But the
interface it presents to user code forms a higher level of abstraction
where these low-level manipulations are hidden away under the hood.


T

-- 
Give me some fresh salted fish, please.