On Tuesday, 10 July 2012 at 22:12:35 UTC, H. S. Teoh wrote:
I don't think we want to change physical (bitwise) const. It
does have
its uses, and it's necessary if you want immutable to work
nicely with
mutable. But if the current const is all we have, then IMO
something is
missing from the language.
The purpose of the recent change is to allow operations like
opEquals and toString on immutable class instances. If there is
no immutable in the loop, you're not gaining anything by using
const.
Even if we had a qualifier for something like logical const -
let's call it lconst - it wouldn't be compatible with the current
immutable and thus not the current const. It would be a separate
system. lconst references would be implicitly convertible to
const references, but not the other way around, equal to the
current issue of not having both mutable and const options for
opEquals and friends. You'd have exactly the same problem.
Exactly, that's what I mean, we're using bitwise const in
druntime in
places where we actually intended _logical_ const. Bitwise
const is a
subset of logical const, and right now the subset is the only
thing we
have.
These changes are *not* to help programmers make methods like
opEquals and toString follow previously implicit rules, they're
here to make these methods work with const (yes, the bitwise
const) and thus immutable.
I suppose the thought was that since const subsumes both
mutable and
immutable, it would be the ideal middle ground. But it turns
out not to
be the case. (Or rather, it _is_ the case, just not quite what
we'd
imagined.)
We knew exactly what this meant for opEquals implementations that
weren't bitwise const but otherwise completely reasonable. I
remember posting about these issues months ago, and I've also
posted in the relevant Github pull request.
I don't think they were rushed. There's been a push for making
druntime
and Phobos const-correct for a while now.
Yes, the discussion has existed ever since const was introduced.
I said I think the proposed solution was rushed, as people had
pointed out several issues with it that nobody were able to
address.
I don't think this change is a
_mistake_ per se, but it does expose a flaw in the language:
const is
too limited in scope, and we need something else to fill in for
use
cases where const isn't good enough.
T
I think this is a red herring. The ultimate goal is to make these
methods work with immutable class instances, which means the
current const is exactly what we want to support.
We just have to make sure to do it in a way that doesn't
compromise on methods requiring mutability. I wish I had a good
solution for that, but the fact that I don't have one doesn't
make the problem any less real.
