A few thoughts on std.allocator

[Peter Alexander via Digitalmars-d]

On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
> 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?

Would it be better to name these after their interpretation, 
rather than expected use cases? For example, the allocator 
doesn't care if something is an array, it cares about resizing, 
and large block allocations. Perhaps s/array/expectRealloc/ (as 
an example). Similar for other ones.

The benefit here is that if, for example, I have some non-array 
use case for frequently reallocing then I can express that 
directly rather than having to pretend it's like an array.