A few thoughts on std.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 5/10/15 5:58 AM, Timon Gehr wrote:
> Keep in mind that currently, entire regions of memory can change from
> mutable to immutable implicitly when returned from pure functions.
> Furthermore, as Michel points out, the ways 'immutable' can be leveraged
> is constrained by the fact that it implies 'shared'.

After sleeping on this for a bit, it seems to me pure function need to 
identify their allocations in some way to the caller. The simplest way 
is to have them conservatively use the most conservative heap. We get to 
refine these later.

For now, here's a snapshot of flags that the allocation primitives 
should know about:

enum AllocOptions
{
   /// Allocate an array, not an individual object
   array,
   /// Allocate a string of characters
   string,
   /// Plan to let the GC take care of this object
   noFree,
   /// This object will be shared between threads
   forSharing,
   /// This object will be moved between threads
   forThreadTransfer,
   /// This object will be mutable after initialization
   mutableTarget,
   /// The caller is a pure function, so result may be immutable
   fromPureFunction,
   /// Object allocated has pointers
   hasPointers,
   /// Typical (default) options
   typical = array | noFree | forSharing | mutableTarget | hasPointers
}

Anything to add to this?


Andrei