Let's not make invariants const

Jonathan M Davis jmdavisProg at gmx.com
Sat Aug 4 01:45:23 PDT 2012


On Saturday, August 04, 2012 10:37:55 deadalnix wrote:
> I don't.
> 
> Actually, it save from many mistakes. You are always free to cast away
> const. This is unsafe, but you are in an invariant and aren't supposed
> to do non const operation. At the end, this is fair.

All that would be required to have a const invariant if invariants aren't 
const by default would be to mark it const. That's how it works with pure 
(unless invariants are always pure now along with const, in which case, this 
is how it _worked_ with pure). So, you can have the extra safety if you want 
it, but as long as invariant is automatically const, you can't safely make in 
non-const, which is unnecessarily inflexible.

D needs to work well with const, but one of the goals is also to make it so 
that it's not required if you don't want to or can't use it. Forcing 
invariants to be const goes against this. But that decision was probably made 
before the recent decisions on Object and const functions (i.e. that toString, 
toHash, opCmp, and opEquals will no longer be part of Object, so you'll be 
able to make them whatever constness you want), and I expect that it'll be 
reverted as long as it's appropriately pointed out to Walter (though it may 
require someone else creating a pull request with the actual changes).

- Jonathan M Davis


More information about the Digitalmars-d mailing list