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