Uh... destructors?

bearophile bearophileHUGS at lycos.com
Tue Feb 22 15:19:15 PST 2011


Steven Schveighoffer:

> I would think malloc and friends should be pure, as well as free.  They  
> can easily simply be marked pure, since they are C bindings.

D even accepts strongly pure functions like:

pure size_t foo() { 
    auto a = new ubyte[1];
    return cast(size_t)a.ptr;
}

For practical purposes D allows pure functions to return dynamic arrays, objects and structs allocated inside them. This is a significant hole in the D idea of purity. I think marking malloc as pure makes the situation worse :-)

This is an idea to patch that hole a little, doing this inside pure functions:
1) Keep disallowing alloca()/malloc()/etc calls;
2) Disallow struct allocations;
3) Keep allowing object and dynamic array allocations;
4) Disallow read and write of the "ptr" fields of dynamic arrays;
5) Disallow casts of object references to something else.

This reduces some flexibility of pure functions, it doesn't fully patch that hole, and makes language rules a more complex.

The idea under those ideas is that objects and arrays are usually interesting for the data/semantics they contain, and not for the value of their pointer. If you ignore the value of their pointer, then the hole vanishes. You can't full close this hole, but those ideas help avoid the more blatantly impure semantics inside/from pure functions.

I'd like to patch that hole, but it can't be fully patched. So maybe all this is useless, or worse it makes the language more rigid and not more safe, so it's probably better to not adopt those ideas.

Bye,
bearophile


More information about the Digitalmars-d mailing list