From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7359f0490512071404o15648ee1l3eabdd3d6dd83b88@mail.gmail.com>
Date: Wed,  7 Dec 2005 14:04:29 -0800
From: Rob Pike <robpike@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] const
In-Reply-To: <874BB1C1-E509-472F-8DBD-9EC0575E2F9B@telus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <571511e7dddc323d94a6da81f35ba899@terzarima.net>
	<874BB1C1-E509-472F-8DBD-9EC0575E2F9B@telus.net>
Topicbox-Message-UUID: be26f812-ead0-11e9-9d60-3106f5b1d025

It's the property of strchr that's truly const, not its arguments.
Expressing this in the arguments leads to this sort of silliness.

I've always thought constancy should be a property of
where something is stored, not its type.  (Hence :rofix
for instance.)

Reiterating what someone said, 'const' is too simple a notion
to encode optimization opportunities and too invasive a notion
to sit well in any practical code.

-rob

On 12/7/05, Paul Lalonde <plalonde@telus.net> wrote:
>
> On 7-Dec-05, at 1:07 PM, Charles Forsyth wrote:
> > 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)
>
> I call this an interface bug: really, it should return a const char
> *, not a char *.  For the case where the input string was not const
> the user can obviously strip the constness from the return value.
>
> It is a clear example of trying to make a piece of notation do two
> things.  One is to say that the function does not modify its
> paramter, which is of clear benefit to the optimizer when calling the
> function.  The second is to say that the data pointed to should not
> be changed, which is a semantic constraint for the programmer.
> Ugly.
>
> Paul
>
>
>