> So it does the optimization possible with const. Not the "interface"
> part, though. If you don't like type decorations, I guess this way's
> better.
it's not so much type decorations, as those that are not terribly useful or to
some extent misleading.
(mind you, java programs look like christmas trees--holiday trees to those of
you in the US--
with all their type and status decorations.)
if you followed the earlier links you'll see one of the classic examples
of it being fairly odd as an interface constraint:
char* strchr(const char* x, int y)
but the resulting pointer points into the const string and ok, it doesn't write
to it itself, but it
hands you back a pointer into the same string so you can do it yourself!
that's wierd, especially since it must effectively have cast x to plain char*
internally
so it's not much of a constraint either way.
i find it's really a device for forcing the adding and removing of const
until a compiler shuts up. this is unusual, because most type clash
diagnostics do mean something;
perhaps not all that much, but something. perhaps i'm lucky, but i have found
bugs through
type clashes (often when checking extern linkages) but i can't remember a
single thing detected by const.
it's one of those things where ``now it's there we might as well try to use
it'' but i'm afraid i'm unconvinced.
