Uh... destructors?

bearophile bearophileHUGS at lycos.com
Mon Mar 21 20:15:31 PDT 2011


Sorry for the late reply to this post, the topic is not easy and I am not sure what the right ideas are:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=130554

Steven Schveighoffer:

> @transparent has little value outside a pure function, because the  
> compiler does not expect to be able to perform pure optimizations on  
>normal functions.  Right now, the only drawback you have shown of being  
> able to compare such references is when that comparison is used as the  
> return value for a pure function.  We can't continue to enforce the  
> @transparent rules when they don't prevent problems, or else the language  
> becomes too burdensome.

You can't drop @transparent (referential transparency attribute, I hae ) until you are outside the pure subgraph of the program, otherwise:

pure int[] foo() { return new int[1]; }
pure bool rnd() { return foo().ptr > foo.ptr(); }


Do input arguments of pure functions need the @transparent attributes? Is dropping it ouside the pure subset of the program safe/acceptable? I think so.


Regarding D purity, currently in D there is no way to tag as pure the result of memoization applied to a pure function. Memoization is just one special case, but it's important. To solve this the compiler has to implement the memoization itself, or a @trusted_pure user annotation is needed... I think the second solution is better, because there is no good way to implement the first, and it's not so much different from the three trusted/safe/system attributes. If a good pure-related idea gets implemented (that is, you are allowed to assign the result of pure functions to const variables with no need of a cast) then @trusted_pure becomes usable to punch another little hole in the const system.

Elsewhere I have tried to explain why having a good and comprehensive implementation of purity will be important in D2:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=132010

Bye,
bearophile


More information about the Digitalmars-d mailing list