http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #22 from Denis Shelomovskij <verylonglogin....@gmail.com> 2012-06-04 13:07:21 MSD --- (In reply to comment #21) > 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). >From your comment before: > 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. `strlen` is now pure (marked by Andrei Alexandrescu) and it can access global state once used with non-zero-ended string. I just made situation more evident. > 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. >From your comment before: > When the compiler can guarantee that all of a pure function's arguments > _cannot_ be altered by that function, _then_ it is strongly pure. So I just don't know how strlen can change its argument... > @system has _nothing_ to do with purity. There's no need to bring it up. IMHO, yes it is. Because @safe and @system pure functions looks very different for me. And yes, I can be wrong. > 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. Does strlen doing something very wrong or specifically trying to break purity when it accessing random memory? > 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. Yes it is because as I wrote: > Once it will have examples showing what asserts have to/may/shouldn't pass > and/or (I prefer and) what optimizations can be done. optimizations = what asserts should pure functions confirm = what is pure function > 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. strlen and other system functions does access global state in some cases. It's pure. And I'm confused if there is no explanation on _how exactly pure functions can access global state_. > 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." No. They call everything that want and do everything they want (see druntme pull 198). They just should behave like a pure functions for a user. And I don't clearly understand what does it mean "to behave like a pure function". That's why this issue is created. That's why I want to see what asserts should pure functions confirm. > That tells you all that you really need to know, > and is quite valuable even if _zero_ optimizations were done based on pure, Again, I'm not interesting in optimizations for optimization now. They just can explain what is a pure function. > 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. It gives me nothing because I still doesn't know what is passed to it as I wrote: > What exactly does these pure functions consider as `argument > value` and as `returned value`? > I think that you're just overthinking this and > overcomplicating things. May be. Just like a contrary case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------