http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #15 from Jonathan M Davis <jmdavisp...@gmx.com> 2012-06-03 14:40:12 PDT --- The _only_ thing that the pure attribute means by itself is that that function cannot directly access any mutable global or static variables. That is _all_. It means _nothing_ else. It can mess with pointers. It can mess with in, ref, out, and lazy parameters. It can mess with the elements in a slice (thereby alterining external state). It can mess with mutable global or static variables _indirectly_ via the arguments that it's passed (e.g if a pointer or ref is passed to a global variable). It just cannot _directly_ access any mutable global or static variables. pure by itself indicates a weakly pure function. That function enables _zero_ optimizations. It is _not_ pure in the sense that the functional or mathematical community would consider pure. It is not even _trying_ to be pure in that sense. What weak purity does is enable _strong_ purity to actually be useful. When the compiler can guarantee that all of a pure function's arguments _cannot_ be altered by that function, _then_ it is strongly pure. Currently, that gurantee is in effect only when all of the parameters of the function are immutable or implicitly convertible to immutable. It could be extended to const parameters in the case when they're passed immutable arguments, but that isn't currently done. A strongly pure function cannot alter its arguments at all, but it _can_ allocate memory, and it _can_ mutate any of its local state. _weakly_ pure functions can therefore be called from within a strongly pure function, because the only state that they can alter is the state of what's passed to them (because the fact that they're marked with pure means that they cannot access mutable global or mutable static state except via their arguments), and the only state that the strongly pure function _can_ pass to them is local to it, because it can't access global or static mutable state any more than they can, and it can't even access it via its arguments, because it's strongly pure. This is all very clear and well-defined. Having pointers sent off into la-la land doing unsafe @system stuff is a _completely_ separate issue. You can break pretty much _anything_ with @system code. You could even cast a function which called writeln so that that the signature was pure and then call it from a pure function. All bets are off when you're in @system land. It's _your_ job to make sure that your code isn't doing something completely screwy at that point. Any function or operation which the compiler doesn't consider pure would still make a templated function be considered impure in such cases, but because it's @system, you can trick it if you want to (e.g. by casting a function's signature). But it's @system code - unsafe code - so it's your fault at that point, not the compiler's. I really don't know how the documentation could be much clearer. ref and pointer arguments are't "returned." Only the return value is returned. And arguments are clearly the arguments to the function. And as long as the compiler can determine that nothing has been done to an argument to alter it, it's going to consider to be the same value (and it's going to be _extremely_ conservative about that - even altering a reference or pointer of the same type would make its value be considered different, because they both might point to the same thing). As for stuff like strlen, in that case, you're doing the @system thing of saying that yes, I know what I'm doing. I know that this function isn't marked as pure, because it's a C function, but I also know that it _is_ actually pure. I know that it won't access global mutable state. So, I will mark it as pure so that it can be used in pure code. I'm telling the compiler that I know better than it does. And in this caes, I do. If I didn't, then you'd have a bug, and it would be the my fault, because they I the compiler what was best, and I was wrong. At that point, it's up to me to make sure that that the compiler's guarantees aren't being violated. That's @system for you. D is a systems programming language. You can do that sort of thing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
