On Monday, 15 November 2021 at 09:42:03 UTC, Ola Fosheim Grøstad wrote:

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)

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

On Monday, 15 November 2021 at 11:58:56 UTC, Stefan Koch wrote:

I wonder if it would be interesting to have a const reference that guarantees that the underlying data-structure does not change as long as the reference or any copies of it are live? I guess that could be another reason for adding tracking of borrowing.

Use case: you obtain a record from a database thread in a transaction, when the transaction is ending the database gets to mutate the record again.

You add the constraint that only @trusted functions are allowed to create such const-references.

On 11/15/21 2:05 AM, Walter Bright wrote:

I mean it's sound in that the type checking is valid. You are allowed to convert mutable to mutable, so having an always-mutable island is a valid. Whether it's confusing or not is a different story, and that part I agree with you.

Without additional type qualifiers, confusion would always remain.

-Steve

On Monday, 15 November 2021 at 09:22:16 UTC, Dukc wrote:

Theres a talk on youtube by Chandler Carruth about llvm / clang optimisation and he says const is litteraly of no use at all.

On Monday, 15 November 2021 at 12:58:46 UTC, Imperatorn wrote:

I am primarily thinking about potential use cases in metaprogramming. For instance: a hashtable that wants to treat keys as binary data and requires the key to be "fully immutable" (you don't want to hash a refcount). The hashtable does not care what the type is, it just want a definitive answer about the key's ability to change. You need more information than this, of course, you also need to know if they key is in a canonical form.

I'm starting to think that the C-style typing isn't really powerful or flexible enough to support meta-programming well. I guess such querying also could be done as a library feature, I think C++ was onto something in their library when they added some information about buffers being contiguous in memory that could be queried. Typing in languages are often on a higher abstract level, but in system level programming one often want machine level knowledge about the concrete representation.

However, doing it on the library level often requires the programmer who build types to take these needs into account, maybe there are opportunities to create robust language level inference that is better? Clearly some things cannot easily be inferred (such as whether the key is in canonical form), but maybe some things can be inferred and that would be interesting to think about.

Yes, you could say that too. Then you are thinking about it in abstract terms.

*offers you a cup of tea*