RFC: moving forward with @nogc Phobos

[Oren T via Digitalmars-d]

On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu 
wrote:
> On 10/1/14, 8:48 AM, Oren Tirosh wrote:
>> On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz 
>> wrote:
>>> [...]
>>>
>>> I'm convinced this isn't necessary. Let's take 
>>> `setExtension()` as an
>>> example, standing in for any of a class of similar functions. 
>>> This
>>> function allocates memory, returns it, and abandons it; it 
>>> gives up
>>> ownership of the memory. The fact that the memory has been 
>>> freshly
>>> allocated means that it is (head) unique, and therefore the 
>>> caller (=
>>> library user) can take over the ownership. This, in turn, 
>>> means that
>>> the caller can decide how she wants to manage it.
>>
>> Bingo. Have some way to mark the function return type as a 
>> unique
>> pointer.
>
> I'm skeptical about this approach (though clearly we need to 
> explore it for e.g. passing ownership of data across threads). 
> For strings and other "casual" objects I think we should focus 
> on GC/RC strategies. This is because people do things like:
>
> auto s = setExtension(s1, s2);
>
> and then attempt to use s as a regular variable (copy it etc). 
> Making s unique would make usage quite surprising and 
> cumbersome.

The idea is that the unique property is very short-lived: the 
caller immediately assigns it to a pointer of the appropriate 
policy: either RC or GC. This keeps the callee agnostic of the 
chosen policy and does not require templating multiple versions 
of the code. The allocator configured for the thread must match 
the generated code at the call site i.e. if the caller uses RC 
pointers the allocator must allocate space for the reference 
counter (at negative offset to keep compatibility).