[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

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



--- Comment #22 from Denis Shelomovskij <verylonglogin.reg at 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: -------