forcing weak purity

Steven Schveighoffer schveiguy at yahoo.com
Wed May 23 04:42:34 PDT 2012


On Wed, 23 May 2012 06:00:11 -0400, Don Clugston <dac at nospam.com> wrote:

> On 23/05/12 07:05, Mehrdad wrote:
>> We should make 'pure' mean strongly pure.
>>
>> For weakly pure, we could introduce the 'doped' keyword :-D
>
> No, the keyword should be more like @noglobal

Well, it's actually @noglobalorshared

> I wish people would stop using this "weak purity" / "strong purity"  
> terminology, it's very unhelpful. (And it's my fault. I've created a  
> monster!)

I think the feature itself is essential and useful.  I just think it's a  
victim of historical naming.

>
> There is absolutely no need for a keyword to mark (strong) purity, and  
> "weak purity" isn't actually pure.

Now that we have the proverbial foot in the door, and we see that weak  
pure... er.. noglobal functions are very useful, it might be worth  
investigating whether it makes sense to rename the keywords.

I agree that 'pure' is somewhat misleading on noglobal functions, simply  
because of the history of the pure keyword in other languages.  But I  
really like how you don't have to care whether a function is actually pure  
or just noglobal, the compiler has a better perspective on what is fully  
pure and what is noglobal.

So are you suggesting that we replace pure wholesale with another keyword  
that better describes what D purity is?  Or are you suggesting that we  
have to specifically mark fully-pure functions as pure to get the benefits?

> The real question being asked is, do we need something for logical  
> purity? Note that we need the same thing for caching.

Yes.  Memory allocation and deallocation is *not pure*, since it affects  
global state.  But it should never participate in optimization.

> Or are the cases like this rare enough that we can just fake it with a  
> cast?

As long as we can have a way to say "this can be called from pure/noglobal  
functions, but should *not* participate in pure optimizations", I think  
it's a valid solution.

-Steve


More information about the Digitalmars-d mailing list