Uh... destructors?

[Jonathan M Davis]

On Tuesday, March 08, 2011 12:17:02 Steven Schveighoffer wrote:
> On Tue, 08 Mar 2011 14:28:44 -0500, Bruno Medeiros
> 
> <brunodomedeiros+spam at com.gmail> wrote:
> > On 23/02/2011 17:47, Steven Schveighoffer wrote:
> >> On Wed, 23 Feb 2011 12:28:33 -0500, Andrei Alexandrescu
> >> 
> >> <SeeWebsiteForEmail at 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