From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <571511e7dddc323d94a6da81f35ba899@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] const
From: Charles Forsyth <forsyth@terzarima.net>
Date: Wed,  7 Dec 2005 21:07:40 +0000
In-Reply-To: <7871fcf50512071130m475c7240i3c65da1b4c900c15@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: be02378e-ead0-11e9-9d60-3106f5b1d025

> 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.