[llvm-commits] [llvm] r136485 - /llvm/trunk/utils/TableGen/

[David Blaikie]

> Sure you can.  What happens when someone accidentally adds a mutating
> method?

Fair enough

> Or forgets about auto-generated operations?

That's an upfront issue - the type wasn't actually made immutable.

> Or derives from said type and adds mutating methods?

Hmm - is there a way to make types underivable in C++03? I don't quite
remember.

>  Or writes code that takes a non-const reference and tries to do something to mutate it?

That's the point - the entire interface has no mutating operations.
It's immutable.

> Or does something in a supposedly non-mutating method that ends up changing
> state?

Could be mitigated by marking the members as const.

> There are lots of ways const can catch logical errors even if the
> underlying type doesn't have mutating methods.

The examples you gave that actually apply are all cases of changing
the underlying immutable type (except for derivation, which is a bit
trickier - but I imagine if it were possible, these types would be
underivable) - which, I agree, is one benefit to const (making sure
the implementation lives up to its end of the bargain, as well as
ensuring clients don't do untoward things).

> I was actually asked to break out the constification change separately,
> which is why this is additionally a bit confusing to me.

One reason being, so that each decision can actually be reviewed
independently. No one went & actually pre-reviewed your code to ensure
that it would be trivially signed off on once it was separated, they
just explained how you could break it up so it could be reviewed. If
you're unsure about certain decisions they can be raised/discussed
before you spend the time to implement them.

(& I'm by no means authoritative here - having committed far less
time/effort/code to this project than you seem to have. Just trying to
help/explain/suggest things)

- David