Memory allocation purity

[via Digitalmars-d]

On Thursday, 15 May 2014 at 11:01:38 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> functions with mutable parameters. It doesn't. And it would 
> actually be very
> difficult for it to do so without doing full program 
> optimization, which
> really doesn't work with the C linking model that D uses.

I think this C linking excuse is used too much :-). Clearly one 
can specify properties of C functions when writing the bindings. 
(Or; should be able to). Besides, not all call trees are full of 
C calls.

> functions. The whole
> purpose of weakly pure functions is to have functions which 
> aren't
> functionally pure but can still be used in functions that _are_ 
> functionally pure.

I take it you mean "expressions" and not necessarily defined 
functions.
So the compiler memoize values derived from weakly pure functions?

> source code for the function available. The only functions for 
> which the
> compiler ever deduces anything from their bodies are templated 
> functions,

But with the amount of templates in phobos… maybe it is time to 
move beyond fully separate compilation units?

> about is the signature of the function. So, it's up to the 
> programmer to tell
> the compiler that a function is supposed to be pure, and it's 
> up to the
> compiler to verify that, and then use that knowledge to infer

Ok, but based on bearophile's example it doesn't verify purity 
properly.

So it is essentially part verified ("verify noglob") and part 
programmer guarantee ("this is pure").

I don't mind programmers being able to set guarantees. For 
instance for a C function or machine language routines it might 
be useful to specify that this is pure and avoid recomputation.

> I agree that that would be great if we were starting over - 
> just like it would
> be great if @safe were the default, but it's too late now. We 
> have to make do with what we have.

Yes, many changes over time is not good. Maybe it would be a good 
idea to collect all those syntax improvements and apply them all 
at once once the semantics are frozen.

> avoid it. And as
> nice as changing some of the attributes around would be nice, 
> it's too big a
> breaking change for too little gain.

It doesn't have to break anything. You could add "@global" and 
"@pure" (strong pure) and keep "pure" (weakly pure) as a 
deprecated feature.