Want reasonable reference counting? Disable automatic sharing of immutable

[Imperatorn]

On Monday, 15 November 2021 at 09:42:03 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 15 November 2021 at 09:22:16 UTC, Dukc wrote:
>> I think he meant from optimisation viewpoint. C++ `const` is 
>> so weak that it can't be used for actual optimisations anyway, 
>> at least usually.
>
> You cannot assume a lot about the underlying C++ object that is 
> accessed through a reference, that is true. But you can infer 
> the constness of functions by static analysis.
>
> The most critical const objects are lookup-tables and one 
> should be able to establish those as immutable in C++ too, as 
> they are const objects that are not accessed through a "remote" 
> pointer.
>
>> So no performance is lost because of `mutable`. In D the 
>> compiler can make some assumption based on `const` and 
>> `immutable`, so we lose some performance potential if we 
>> implement `mutable`.
>
> Maybe, although it is kinda the same as having a mutable object 
> with mostly immutable fields.
>
> So, I would think that could be covered by having a mechanism 
> for inferring "full immutability"?

Would a new keyword be required or would it be enough to specify 
it so that optimizations could be done etc? (So that we don't 
loose the "benefits" we have today). Sorry, I'm writing this the 
fly so haven't thought this through.

For me the right solution though seems to be keeping it 
"external".

Why? Don't touch the object, the usage of it is not of it's 
concern.

If we view it as a canonical object like the number 7, we don't 
keep track in the object itself where it's used. When we bring it 
from the platonic to the physical world by "instantiating" it as 
a copy. If you destroy our copy, the canonical (eternal) object 
doesn't change.

Hence, it makes more sense to keep track of it in a separately, 
maybe even in another universe (depending on interpretation).

You can view it as what's happening is something like you get a 
copy of the entire universe with one bit changed, let's say a 
count variable x (I'm only using natural numbers here). The 
canonical values lives outside the omniverse.

In this example a universe can bind a canonical value to a 
variable and observe the value of a variable. I have also thrown 
in the successor function (suc(n) = n+1) and predecessor function 
(pre(n+1) = n) because why not (this is pseudo for the sake of 
discussion)

```d
Universe u0 = Omniverse.getUniverse(0); //You reference a 
universe by a natural number or view it as a new Universe() where 
the omniverse sets the "blueprint", this boils down to the 
interpretation

// Bind 7 to x, it just means that the (canonical value from the 
platonic domain) of 7 is stored within the universe as a 
(imperfect or perfect (hopefully)) representation (data)
u0.bind(x, 7);

// What's happening here is another canonical value is being 
bound and put into x (yes I know)
u0.bind(x, suc(u0.observe(x))); //This is (if the observation is 
not corrupted etc) equivalent with u0.bind(x, 8)

// A new universe would get x = 8 here
Universe u1 = u0; // Create a new universe by copying an old one 
from the omniverse (or not, depending on your interpretation, I 
don't have time to write both atm)

u1.bind(x, pre(u1.observe(x))); // Bind x in this universe to the 
predecessor of x
u1.observe(x); // Would observe 7

// The philosophical discussions begin here...

// Should/can u1 be able to observe something in u0, if so, how?
// What makes the omniverse consistent?
// etc etc, not so interested in this atm :)
```

So the hierarchy would be
Platonic -> Omniverse -> Universe -> Data -> Information 
(interpreted data)

The destruction (removal), mutation (intentional change) or 
corruption (unintentional change) of a variable does not in any 
way make its way up the hierarchy by other than explicit copy 
(using that interpretation), it's contained within the universe 
or can only move horizontally.

How does this relate the question at hand?
In the way that you keep the count separate from the object.

The mapping between the count and the object is just a matter of 
what relation exist in the universe (or even between universes 
depending on the interpretation etc).

One could easily imagine a model where there are multiple 
views/counts of an object in different environments.

So, in essence, if you want to keep a count of something you 
should probably do it separately. I think it has a higher 
probability of being correct, but the con is it will probably 
impact performance a bit (I have no solid stats on it, I'm just 
guessing).

As I see it all boils down to if you view the universe as 
something that mutates itself recursively or that the universe is 
always new with every iteration ie Bohr vs Heisenberg etc.

Wait, is this even the right thread. Nvm, I'll post it here

Now I'm late for lunch and it's your fault! *raises fist*