Steven Schveighoffer wrote:
> "Bruno Medeiros" wrote
>>> I guess it all depends on what you consider partially pure :)  I believe the current rules as stated on D's website require invariant return data, or data that can be implicitly cast to invariant.
>> In Andrei's latest presentation (http://www.digitalmars.com/d/2.0/accu-functional.pdf)
>> when he lists the requirements for pure, it does not say that is should return invariant data. (and I'm assuming those requirements are complete)
> 
> Those requirements are not complete.  For instance, the web site says that pure functions can call new expressions, but that is not stated in the pdf (or at least, I don't remember seeing it).  I think it will eventually be stated that pure functions initially will have to return invariant data, or data that can be implicitly cast to invariant.  Unless I can convince Andrei otherwise :)
> 
> -Steve 
> 
> 

It's not stated in the pdf "that pure functions can call new expressions" because it only states what pure functions *cannot* do. What they can do is everything else. So new expressions are allowed (likely following the same rules as function calling, ie, only pure constructors are allowed).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

I'm not an expert on D, but it looks like a pretty nice language.  While reading about 'pure' recently, however, I found what appeared to be pretty major usability problems with the idea as it was presented:

- Pure functions can have local mutable state, but aren't allowed to factor the logic for manipulating that state out into functions (since such a function would be non-pure).

- Pure functions can't be applied to mutable data.  So you potentially need a mutable non-pure version of each pure function.

An elegant solution to both of these problems would seem to be the one proposed in this thread - get rid of the requirement that parameters be invariant.  The first problem above is solved by pure functions with mutable parameters, and the second by pure functions with const parameters.

Special optimizations that require purity and parameter invariance can always be done by creating a specialized version of each pure function that's invoked when the arguments are known to be invariant.  Let the compiler handle the duplication - don't make the programmer copy/paste.

Thanks

On Fri, 01 Aug 2008 03:46:30 +0200, mort <mortm@gmail.com> wrote:

> - Pure functions can't be applied to mutable data.  So you potentially need a mutable non-pure version of each pure function.

I would believe the following to work:

pure SomeStruct foo(invariant SomeStruct f);

foreach (ref s; SomeStructArray)
	s = foo(cast(invariant)s);

-- 
Simen