Forcing weak-pure

[Artur Skawina]

On 03/25/14 14:30, Steven Schveighoffer wrote:
> Of course naturally, with all things this low-level, we have to make decisions as to what is *provably* @safe/pure/nothrow, and what is *logically* @safe/pure/nothrow. The most obvious example is memory allocation -- It is technically not pure as it accesses global state (the heap), but we can rationalize making it pure since we have more logical knowledge of the situation than the compiler (i.e. locking the global heap, and realizing that if a block is unallocated, it is uniquely accessed with the allocation of it).

On 03/26/14 00:30, Artur Skawina wrote:
> It's ok to treat allocator and factory functions as pure, because those really
> are logically pure, ie can't affect any /visible/ state and return results that
> are unique.

That was wrong; treating these funcs as pure won't work. While allocator functions
have some traits of pure ones -- no side-effects, their result only depends on the
args, and the call can be optimized out when the result in unused -- there is one
difference, which isn't expressible in D: the uniqueness of the result. Letting them
be pure would mean that important purity based optimization could not be allowed
(so that "S* s1 = makeS(32), s2 = makeS(32);" does not break).

But this case is easy to deal with -- it's enough to (1) mark the alloc funcs with
a 'malloc' attribute, (2) allow calling @malloc functions inside pure ones.

artur