On Tuesday, 16 February 2016 at 07:20:00 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright
wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head const will do for us:
1. make it easy to interface to C++ code that uses const, as
currently it is not very practical to do so, you have to
resort to pragma(mangle)
2. supports single assignment style of programming, even if
the data is otherwise mutable
The downside is, of course, language complexity.
Maybe you can get away with adding "mutable", which is needed
for intrusive ref counting as well:
C++:
Type * const ptr;
struct ConstType {
mutable int rc;
}
D:
const mutable(Type)* ptr;
struct ConstType {
mutable(int) rc;
}
For that to work in D, we'd lose out on the guarantee that a
const object can't be mutated via a const reference to that data
- though with the current state of things, const does become
limiting enough that you can't use it under a number of
circumstances that you might like to (e.g. ref-counting), and
some folks mistakenly think that it's defined behavior to cast
away const and mutate and do it in their code. So, such a change
might be worth it, but it's not something that should be
considered lightly. If we did go that route though, having
mutable or @mutable would allow for it to be much more controlled
than simply casting away const and mutating (e.g. it could
guarantee that no immutable objects were involved, since an
object with an @mutable member couldn't be immutable, since that
would violate immutable).
But even if we went that route, that's still a whole other
ballgame from non-transitive const. There are some major
implications for const if we making it legal to cast it away and
mutate as long as the underlying data is mutable rather than
immutable, but from a language complexity standpoint, it's not
particularly problematic, whereas non-transitive const is.
- Jonathan M Davis
