[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #21 from Jonathan M Davis <jmdavisProg at gmx.com> 2012-06-04 01:22:53 PDT ---
???

Why would you be marking a function as pure if it can access global state? The
compiler would flag that unless you cheated through casts or the use of
extern(C) functions where you marked the declaration as pure but not the
definition (since pure isn't part of the name mangling for extern(C)
functions).

Also, none of your examples using in are strongly pure. At present, the
parameters must be _immutable_ or implicitly convertible to immutable for the
function to be strongly pure. The only way that const or in would work is if
they were passed immutable arguments, but the compiler doesn't treat that as
strongly pure right now.

@system has _nothing_ to do with purity. There's no need to bring it up. It's
just that @system will let you do dirty tricks (such as casting) to get around
pure. Certainly, an @system pure function isn't pure based on its arguments
unless it's doing something very wrong. The function would have to be
specifically trying to break purity to do that, and then it's the same as when
you're dealing with const and the like. There's no need to even bring it up.
It's a given with _anything_ where you can cast to do nasty @system stuff.

Adding a description of weakly pure vs strongly pure to the documentation may
be valuable, but adding any examples like these would be pointless without it.
Also, if you'll notice, the documentation in general is very light on
unnecessary examples. It explains exactly what the feature does and gives
minimal examples on it. Any that are added should add real value.

pure functions cannot access global mutable state or call any other functions
which aren't pure. The compiler will give an error if a function marked as pure
does either of those things. What the compiler does in terms of optimizations
is up to its implementation. I don't see how going into great detail on whether
this particular function signature or that particular function signature can be
optimized is going to help much.

It seems to me that the core problem is that many programmers are having a hard
time understanding that all that pure means is that pure functions cannot
access global mutable state or call any other functions which aren't pure. They
keep thinking that it means more than that, and it doesn't. The compiler will
use that information to do optimizations where it can (which aren't even always
related to strongly pure - e.g. combining const and weakly pure enable
optimizations, just not the kind which elide function calls). If programmers
would just believe what the description says about what pure means and stop
trying to insist that it must mean more than that, I think that they would be a
lot less confused. In some respects, discussing stuff like weakly pure and
strongly pure just confuses matters. They're effectively implementation details
of how some pure-related optimizations are triggered.

It's so very simple and understandable if you leave it at something like "pure
functions cannot access global or static variables which are at all mutable -
either by the pure function or anything else - and they cannot call other
functions which are not pure." That tells you all that you really need to know,
and is quite valuable even if _zero_ optimizations were done based on pure,
because it helps immensely in being able to think about and understand your
program, because you know that a pure function cannot mutate anything which
isn't passed to it. I think that you're just overthinking this and
overcomplicating things.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------