On 11/15/2015 03:17 PM, Timon Gehr wrote:
On 11/15/2015 08:57 PM, Andrei Alexandrescu wrote:
On 11/15/2015 01:50 PM, Jonathan M Davis wrote:
On Sunday, 15 November 2015 at 18:09:15 UTC, Andrei Alexandrescu wrote:
On 11/15/2015 01:00 PM, Jonathan M Davis wrote:
Basically, we have to decide between having physical const with the
guarantees that it provides
We have that - it's immutable. -- Andrei
Yes and no. As it stands, I can know that
const foo = getFoo();
foo.bar();
won't mutate foo unless I have another, mutable reference to foo
somewhere that bar somehow accessed.
That is an illusion, and we need to internalize that. Consider:
// inside some module
struct T
{
int[] data;
void bar()
{
// look, ma, no hands
g_data[1]++;
}
}
static int[] g_data;
const(T) getFoo()
{
T result;
result.data = g_data = [1, 2, 3];
return result;
}
...
This is the exact exception he described i.e. "unless I have another,
mutable reference to foo somewhere that bar somehow accessed."
Nope. He doesn't have a reference; the implementation has
surreptitiously, without the caller's knowledge.
Big difference! That means the modular typechecker cannot make any
assumption about the immutability of that object.
Let me repeat: const is already as weak as some fear it might be.
(Immutable is fine.)
(Also, 'bar' should be 'const'.)
Right.
In other words, you truly need access to the implementation of getFoo()
in order to claim anything about the changeability of stuff.
No, e.g., make either 'getFoo' or 'bar' pure.
Well but it's not. Keep the goalposts where they are. This is about
"const". I do agree that "pure const" may have other, stronger
properties. But let's discuss "const" and what it can promise, or move
over to a whole new topic of "pure const".
Note that I
could even afford to have getFoo() return const, so no need for the
caller to make it so!
With immutable, it's all cool. Immutable data is truly immutable, and
that can be counted on. But const, even today, cannot be assumed to be
as strong.
...
This is obviously true (it is what justifies the distinction between
const and immutable in the first place), but this is not a way to
justify making it weaker.
Weaker than what? I've just shown black on white it's not a guarantee of
constant data. Today. With no compiler bugs in sight.
This is all just moving in the direction of a
setting where all structs/classes just prevent immutable construction
and make all member functions const, and const becomes the new mutable.
I don't see the point.
I don't understand this.
Andrei
