Stuff D will do:
http://lwn.net/Articles/285332/

Bye,
bearophile

On Sat, 21 Jun 2008 03:53:24 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Stuff D will do:
> http://lwn.net/Articles/285332/
>
> Bye,
> bearophile

Nice. But can't see why strlen is pure (in the article):
int __attribute__((pure)) strlen(const char* string) {
	return /* you know what */;
}

char* someString = "Hello";
int len1 = strlen(someString);
someString[4] = 0;		// guess what is it now? :)
int len2 = strlen(someString);	// input is *not* changed

One thing they lack is an invariant type.
And the main problem is that it is not standardazed, so it is not portable across compilers.

== Quote from Koroskin Denis (2korden@gmail.com)'s article
> On Sat, 21 Jun 2008 03:53:24 +0400, bearophile <bearophileHUGS@lycos.com=
> >  =
> wrote:
> > Stuff D will do:
> > http://lwn.net/Articles/285332/
> >
> > Bye,
> > bearophile
> Nice. But can't see why strlen is pure (in the article):
> int __attribute__((pure)) strlen(const char* string) {
> 	return /* you know what */;
> }
> char* someString =3D "Hello";
> int len1 =3D strlen(someString);
> someString[4] =3D 0;		// guess what is it now? :)
> int len2 =3D strlen(someString);	// input is *not* changed
> One thing they lack is an invariant type.
> And the main problem is that it is not standardazed, so it is not portab=
> le  =
> across compilers.

I don't think "invariant" is a necessary condition for pure functions.  The
only reason invariance matters at all for pure functions is if the data is
shared across threads in such a manner that concurrent modification
may occur while the pure function is executing.  And this is such a bad
idea anyway that I don't see any reason to support it in language.
Personally, I'd much rather have pure functions be able to accept "const"
parameters to avoid all the casting that will happen with the current
approach.


Sean