Inherited const when you need to mutate

[Jakob Ovrum]

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.