Transitive const sucks

James Dennett jdennett at acm.org
Wed Sep 12 22:03:05 PDT 2007


Walter Bright wrote:
> Janice Caron wrote:

[snip]

>> And to argue that "they aren't const" is a
>> matter of definition. "const" in C++ is /defined/ to mean logical
>> const, so const they are! You use the word to mean "physically const".
>> We don't all agree on the definition.
> 
> C++ invented the term "logical const" because people clearly were
> surprised by const references not being constant. 

The term may be new from the C++ community, but the notion
is much, much older, and it's certainly nothing much to do
with "const references not being constant".

In an OO world, objects perform actions in response to
messages that they receive.  Logical constness means
that their responses to those messages are unchanged.
It's not about implementation details such as internal
state.  Logical const is about an interface, and it's
not a C++ idea, though C++ helped to clarify it.

> But that's not really
> relevant here, what is relevant is what is the right definition of const
> for D.

"Those who cannot learn from..."

We can't ignore learning from the history of immutability
and of read-only views in other languages if we want to
find what's best for D.  (That doesn't, of course, mean
that new ideas shouldn't also be explored.)

> I think D should have an intuitive, useful, and checkable notion
> of const.

These may be forces that are in conflict; coming up with
something in the sweet spot is the challenge.  (It may be
that in some areas some of these ideas are complementary,
which is nice when it happens.)

C++'s const seems intuitive to many of us, but not to others.
It's checkable in some sense, but not in another.  It's not
much use for optimization (though it is some).  And it's very
useful, though Walter disagrees with that assessment.

Logical const reflects something meaningful at an interface
level.  Deep physical const isn't so useful there; you might
have an const id, identifying a changing external resource:
indirection sinks any attempt to make enforceable const
reflect actual unchanging behavior, unless you take it much
further in the direction of "pure".  Physical const is an
implementation detail.  Logical const is an interface issue.
Tools can deal more easily with implementation issues than
with design issues, but we shouldn't let the tools get in
the way of good design.

> C++'s is not intuitive, marginally useful, and not checkable.

Just thought we should flag that last sentence as subjective
propaganda in case anyone still thought Walter was bizarrely
neutral on the C++/D discussions >;-)

-- James



More information about the Digitalmars-d mailing list