[phobos] Unique

[Martin Nowak]

On Sat, 11 Feb 2012 01:37:47 +0100, Martin Nowak <dawg at dawgfoto.de> wrote:

> On Fri, 10 Feb 2012 21:18:46 +0100, Andrei Alexandrescu  
> <andrei at erdani.com> wrote:
>
>> On 2/10/12 11:42 AM, Martin Nowak wrote:
>>> On Fri, 10 Feb 2012 16:35:18 +0100, kenji hara <k.hara.pg at gmail.com>  
>>> wrote:
>>>
>>>> I think std.typecons.Unique should place the object ownership under
>>>> the control.
>>>> Unique!T holds the unique ownership of given object typed T.
>>>> yes, Unique can hold an object on heap, but also should be able to
>>>> hold stack allocated object.
>>>> (In this case, Unique!T will work as rebindable scoped!T, IMO)
>>>>
>>>> An experimental implementation of mine.
>>>> https://github.com/9rnsr/scrap/blob/master/typecons/unique.d
>>>>
>>>> Kenji Hara
>>>>
>>> Can you give an example where a unique value type is useful.
>>
>> Transferring ownership across threads. Thanks Kenji for working on  
>> this. An essential aspect will be to get the move right.
>>
>> Andrei
>>
> I probably miss the point but here is what I see.
> Values are unshared by default so transferring ownership
> only make sense for structs owning shared resources.
> To make this safe you'd need to enforce uniqueness for all fields as  
> well.
> Aliasing and static values are corner cases of that rule.
>
> What I wanted to add is a unique_ptr like construct to help
> reducing the pervasive use of GC memory for unshared objects.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Well the obvious example is are files or any kind of handles.
So unique can't enforce uniqueness when being created but helps
to avoid accidental duplication.

It seems like a unique_ptr construct would be most helpful after
the allocator interface is known. It could probably still use Unique
if the allocated object is wrapped in a struct that does the freeing.