On Tuesday, March 08, 2011 12:17:02 Steven Schveighoffer wrote:
> 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.
@safe is for compiler-verified safety. @trusted is for programmer-verified
safety.
- Jonathan M Davis
