const only has a meaning in presence of aliasing. Unique const data is meaningless. const is abstract. strongly pure functions should not be allowed to return const; they can return mutable or immutable data instead.
static assert(!is(typeof(new const(Object))));
static assert(!is(typeof(new const(int)[1])));
static assert(!is(typeof({const(Object) foo(){return new Object;}})));
static assert(!is(typeof({const(int)[] foo(){return new int[1];}})));
Comment #1 by issues.dlang — 2012-01-18T13:55:00Z
I can see why it would be considered bad practice to return const from a strongly pure function, but why should it be disallowed by the compiler?
Comment #2 by timon.gehr — 2012-01-18T14:25:22Z
Immutable has all the constraints const has and gives actual guarantees. I don't think it is very important to enforce it, but it would be a net gain.
Comment #3 by clugdbug — 2012-06-27T00:06:13Z
It is currently possible to declare 'const int' variables even though they are identical to 'immutable int' ones. This is similar.
And consider:
const[] foo(S y) pure { ... }
With this proposal, that's OK for struct S, as long as the struct has a pointer.
But if S has no pointers, the return value needs to be immutable.
That's just annoying.
This proposal doesn't add any value.