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
