On Tue, 08 Mar 2011 14:28:44 -0500, Bruno Medeiros
<brunodomedeiros+spam@com.gmail> wrote:
On 23/02/2011 17:47, Steven Schveighoffer wrote:
On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 2/23/11 11:16 AM, Steven Schveighoffer wrote:
Just because a function is not marked @safe does not mean it is
unsafe.
It just means you can do things the compiler cannot verify are safe,
but
that you know are actually safe. I showed you earlier an example of a
safe pure function that uses malloc and free.
Programmers are allowed to make conceptually safe functions which are
not marked as @safe, why not the same for pure functions?
-Steve
I understand that. My point is that allowing unsafe functions to be
pure dilutes pure to the point of uselessness.
And that's not a point. It's an unsupported opinion.
pure has nothing to do with safety, it has to do with optimization. Safe
functions are no more optimizable than unsafe ones. Safety has to do
with reducing memory bugs.
The two concepts are orthogonal, I have not been convinced otherwise.
-Steve
pure has something to do with @safety. (Also, it has more to do with
than just optimization, it also affects code readability.)
In order to gain any benefit from calling pure functions (whether the
benefit is programmer code readability or compiler optimization) it
needs to be determined from the pure function's signature what is the
transitively reachable mutable state that the function may access.
Normally this state is whatever is transitively reachable from the
parameters. However, if you allow *arbitrary* _pointer arithmetic_ you
could legally manipulate any mutable data in your program from within
the pure function. This would make the pure attribute useless because it
would not offer any additional guarantees whatsoever over an unpure
function. So such a rule is necessary such that, for example, the
following function should not be allowed to be pure:
pure int func(int* ptr, int ix) {
return (ptr + ix)++;
}
If I want to make my own array type, then it will be quite unusable in
such pure functions.
Assuming that such code is illegal assumes the compiler fully understands
the semantic meaning of that code.
Keep in mind that an array is semantically understood by the compiler, but
I can't convey that same semantic knowledge to the compiler for my custom
type. I may know that some pointer arithmetic is perfectly safe and pure,
even when the compiler cannot grok that. It doesn't make sense that pure
functions shouldn't be allowed to be streamlined/optimized as I can normal
functions. To me the concepts of @safe and pure are still orthogonal.
@safe is not so much about "safety" as it is about "compiler-verified
safety". I feel somewhat the words are getting in the way here. I don't
mean memory unsafe code, I mean memory safe code that cannot be compiler
verified via @safe. I feel that because the compiler can't verify pure
functions are memory safe doesn't make pure functions unusable or useless.
-Steve
