Why do immutable variables need reference counting?

[wjoe]

On Monday, 11 April 2022 at 03:24:11 UTC, Ali Çehreli wrote:
> On 4/10/22 20:05, norm wrote:
> > On Sunday, 10 April 2022 at 23:19:47 UTC, rikki cattermole
> wrote:
>
> > In my mind immutable data
> > means the data will not change and neither will the result of
> reading
> > that data, ever.
>
> Yes.
>
> > I don't get how you can have thread safety guarantees based
> on immutable
> > if reading that data in a thread suddenly becomes undefined
> behaviour
> > and could return anything.
>
> Yes, it would be a bug to attempt to read data that is not live 
> anymore.
>
> > That isn't immutable then.
>
> The lifetime of immutable data can start and end.
>
> import std.stdio;
>
> struct S {
>   int i;
>
>   this(int i) {
>     this.i = i;
>     writeln(i, " is (about to be) alive!");
>   }
>
>   ~this() {
>     writeln(i, " is (already) dead.");
>   }
> }
>
> void main() {
>   foreach (i; 0 .. 3) {
>     immutable s = S(i);
>   }
> }
>
> The output:
>
> 0 is (about to be) alive!
> 0 is (already) dead.
> 1 is (about to be) alive!
> 1 is (already) dead.
> 2 is (about to be) alive!
> 2 is (already) dead.
>
> Module-level immutable and 'static const' would live much 
> longer but they have a lifetime as well. However, today, the 
> destructor cannot be executed on an immutable object, so I 
> remove the qualifiers with cast(), which sohuld be undefined 
> behavior (today?).
>
> immutable(S) moduleS;
>
> shared static this() {
>   moduleS = S(42);
> }
>
> shared static ~this() {
>   destroy(cast()moduleS);
> }
>
> void main() {
> }
>
> > Once instantiated
> > immutable data persists for the remainder of the program.
>
> That seems to be the misunderstanding. Again, I think 
> module-level 'immutable' and 'static const' data fits that 
> description.
>
> > You may not
> > have access if the variable goes out of scope, but if you do
> it will
> > always be there and always return the same value when you
> read from memory.
>
> That description fits D's GC-owned data (including immutables). 
> The lifetime ends when there is no reference to it.
>
> Another example is immutable messages passed between threads 
> with std.concurrency: That kind of data clearly originates at 
> run time and the receiving end keeps the data alive as long as 
> it needs.
>
> Ali

To my understanding immutable data should reside in a separate 
data segment which itself could reside in ROM.
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.
Due to its immutable nature immutable data can't be changed and 
this, to my understanding, includes deallocation. And because the 
data could be in ROM any modification is an error. How would you 
deallocate ROM anyways?
Your foreach could be unrolled at compile time, however it could 
easily be changed to a runtime only loop but this entire concept 
of creating immutable data on the fly doesn't make sense to me - 
that should be const's domain. Strings, I know. But the way 
things are, I hardly see a difference between immutable and const.