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).
