Re: Why do immutable variables need reference counting?

[wjoe via Digitalmars-d-learn]

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?