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