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
