🚀 go-pugleaf

Another way to view "const" is as a language rule. For example,
"2 := 3" is usually not allowed, and not many folks argue
that it should be allowed: clearly there is a well understood
"const" quality to literals. 

In C/C++, const value arguments are useful as a safety check,
particularly given the increased use of macros which may hide
attempts to change the value of an argument. const references
& pointers (actually pointers to const) are also extremely
useful from an API specification standpoint as they clearly
point out (and enforce assuming no casting is used) which
arguments can/will be changed by a routine.

In Eiffel, values of arguments are already "const", but there is still
the question of how to make references "const". Pre/Post-conditions
help to some degree, but not only does this defer detection until
run-time it also makes enforcement "optional" since checking
of pre/post conditions is itself optional. Also, lets look at
a relatively simple example of ensuring that a STRING is not
modified:
 class xxx
 ...
    no_touch(s: STRING) is
      require
        s_exists: s /= Void
      do
        ...
      ensure
        ???
      end
 end

How do we encode the (dynamically checked) postcondition?

1) s = old s -- won't work since this just checks that the object
referenced by s is the same object, not that the object didn't change
(Since the value of s cannot change, this check in fact is worthless)

2) s.is_equal(old s) -- won't work either (since s = old s, the
field-by-field comparison of s and itself is essentially useless)

3) declare a local string, copy s into at, and check at the end
of the routine? Can't do it since Eiffel (the language) doesn't
allow use of locals in postconditions (NOTE: some vendors do allow
this as an vendor dependant extension)

4) add a field to xxx where s is copied into and check at the end
of no_touch? Doable, but ugly and slow.

OTOH, in C/C++ this specification is easy and statically checkable:
 no_touch(String const * const s) {
   ...
 }

[Note const routines (i.e. routines that do not change the object
used to invoke them) are an automatic necessity once const arguments
enter the language]

Granted the initial introduction of "const" into an existing class
library is painful, but I think definitely worth it. For classes
being written from scratch I find there to be no incremental cost
in appropriate use of "const" arguments.

As to const function results, I think it necessary to allow for them.
For example, given CONTAINER[Const STRING], any function returning
an item from that container should return it as a "Const STRING".

Yes it may be possible to emulate const in Eiffel via duplicate
class definitions (i.e. writable, read-only), but not completely
and not efficiently (both in development and execution).

What I would like to see in both Eiffel & Java is "const constness"
in which the semantics of C/C++ const are available without the
ability to override (via casting in C/C++, inheritance in Eiffel).