Why do immutable variables need reference counting?

[Ali Çehreli]

On 4/11/22 05:57, wjoe wrote:

 > To my understanding immutable data should reside in a separate data
 > segment which itself could reside in ROM.

We are getting into implementation details which a programming language 
acts as not to care (but has to do especially when it's a system 
programming language like D. :) ).

 > So when the variable, or 'pointer' to the data, goes out of scope just
 > the 'pointer' is gone, the actual data unreachable, but still there.

I think it translates to the destructor never being executed. Otherwise, 
nobody would even know whether the memory location is reused for other 
pursposes later on.

 > Due to its immutable nature immutable data can't be changed and this, to
 > my understanding, includes deallocation.

D one language where object lifetime is deliberately separate from 
memory allocation.

 > And because the data could be
 > in ROM any modification is an error.

Fully agreed. However, how could I initialize such an object then? (You 
may have meant a read-only memory page instead of ROM.)

 > immutable data on the fly doesn't make sense to me - that should be
 > const's domain.

Even 'const' cause confusions because it's used in at least two 
different ways (even e.g. in C++):

1) I will not mutate data through this reference. For example, a 
parameter that is pointer to const achieves that:

   void foo (const(int)[] arr);

2) This variable is const:

   const i = 42;

Well, there is the confusion: There is no "reference" in the second case 
at all!

I don't agree with you when you say immutability should be const's 
domain because const covers item 1 above as well, where there is no 
immutability of data whatsoever. The data may be perfectly mutable or 
immutable, where my access will be readonly.

Perhaps you are saying the same thing but enters D's immutable: The data 
is immutable.

immutable data on the fly can be very useful because e.g. it makes 
multithreaded programming trivial in some cases by removing the need for 
locking.

 > Strings, I know. But the way things are, I hardly see a
 > difference between immutable and const.

Imagine a File struct that holds on to a file name. In C++, we would 
have to make a copy of the constructor argument for two reasons:

1) Lifetime of the object might be short. This is not a problem in D 
because of the GC.

2) The data might change after I start holding on to it through a 
reference. This is not a problem *only if* data were immutable because 
my const parameter cannot preclude the producer from mutating it 
further. Example:

import std.stdio;
import std.format;

struct S {
   const(char)[] fileName;

   this(const(char)[] fileName) {
     this.fileName = fileName;
     report();
   }

   ~this() {
     report();
   }

   void report(string func = __FUNCTION__) {
     writefln!"%s working with %s."(func, fileName);
   }
}

void main() {
   char[] fileName = "foo.txt".dup;
   auto s = S(fileName);
   fileName[0..3] = "bar";
}

The output shows that the file name changed between construction and 
destruction:

deneme.S.this working with foo.txt.
deneme.S.~this working with bar.txt.

If fileName were immutable, then the owner would not be able to mutate 
anyway, so the struct could get away without copying the file name.

Ali