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
