On Wed, 26 Mar 2014 10:36:45 -0400, Kagamin <spam@here.lot> wrote:

> On Tuesday, 25 March 2014 at 23:30:28 UTC, 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.
>
> Allocators don't return unique results, GC being the primary example.

I think you misunderstand. The result is uniquely referenced, meaning no other pointers to the data are present (except the all-seeing heap).

Multiple calls to the allocator may return different results, and each result is uniquely referenced.

-Steve

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

On Sat, 05 Apr 2014 08:26:01 -0400, Artur Skawina <art.08.09@gmail.com> wrote:
> 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).

I think this still works, even if makeS is pure, since it would be weak-pure.

-Steve