Why do immutable variables need reference counting?

[wjoe]

On Monday, 11 April 2022 at 22:10:07 UTC, Ali Çehreli wrote:
> On 4/11/22 05:57, wjoe wrote:
>
> > 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.)
>

I was thinking during compile time. By initializing a variable 
with immutable data or a pointer that points to an address e.G. 
an EEPROM.

> 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!

In general, I guess, it's a bad idea to reuse the same word for 2 
or more distinctly different ideas. Maybe the const keyword in 1) 
should have a better name. Especially since it's only a promise 
and the compiler accepts this:

void foo (const(char)[] arr)
{
   cast(char[])arr[0..3] = "baz";
}
string bar = "123";
foo(bar);
assert(bar=="baz");

But I could cast away const and modify the string bar.

So with that said
> 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.

When I said immutability should be the domain of const I am 
referring only to 2).

I.e. immutable is constant data which is created at compile time 
- like laws of physics,
const as in 2) is constant data which is created at run time - 
like man made laws,
and 1) should get a better name - maybe 'in' and get rid of const.

And to be able to use immutable anywhere other than where 
immutable is explicitly specified, a copy is necessary.

I know it's not as simple as that. But one can dream, right? :)

> 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";
> }
>
>
> 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

I presume you refer to fileName in main() ? And if yes, if it 
were const, it couldn't be mutated either, so isn't immutable and 
const sort of synonymous in that case or am I missing your point?