On Wed, 22 Sep 2010 13:10:36 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 22 Sep 2010 12:00:16 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Wed, 22 Sep 2010 11:53:22 -0400, Don <nos...@nospam.com> wrote:
Robert Jacques wrote:
On Wed, 22 Sep 2010 04:13:34 -0400, Don <nos...@nospam.com> wrote:
Don wrote:
The docs currently state that:
PROPOSAL:
Drop the first requirement. Only one requirement is necessary:
A pure function does not read or write any global mutable state.
Wow. It seems that not one person who has responded so far has
understood this proposal! I'll try again. Under this proposal:
Funny, your re-iteration appears to coincided to my previous
understanding. So either I've mis-understood twice, or I didn't
sufficiently demonstrate my understanding when I made my critique. :)
That said, I do think this version is much clearer and understandable.
If you see a function which has mutable parameters, but is marked as
'pure', you can only conclude that it doesn't use global variables.
That's not much use on it's own. Let's call this a 'weakly-pure'
function.
However, if you see a function maked as 'pure', which also has only
immutable parameters, you have the same guarantee which 'pure' gives
us as the moment. Let's call this a 'strongly-pure' function.
The benefit of the relaxed rule is that a strongly-pure function can
call a weakly-pure functions, while remaining strongly-pure.
This allows very many more functions to become strongly pure.
The point of the proposal is *not* to provide the weak guarantee. It
is to provide the strong guarantee in more situations.
The problem from my point of view is that the programmer can not
declare that a function should be 'strongly-pure' or 'weakly-pure'.
Yes they can. They just need to declare the parameters to be immutable.
What about value types?
Value types are implicitly convertable to immutable, so they can be
strongly-pure.
No their not. Remember, arrays and other structs are value types in the
type system. Logically, they may be reference types, but as far as their
type signature goes, they are value types.
The problem I think Robert is referring to is, a person cannot always
tell just from looking at a signature that a type is strongly-pure
qualified or not.
And that you can not manually specify one or the other.
For example, is this function weak or strong?
pure int foo(T t);
But the compiler will be able to tell. I think adding a
__traits(isStronglyPure, symbol) will be good for those rare occasions
where you really want to ensure purity.
static assert(__traits(isStronglyPure, foo));
-Steve
This would work, but it wouldn't be self-documenting, etc.
