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.
