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.
