I'll take a shot at implementing std.typecons.Unique.
Any opinions or ideas?

My main goals is that it should use malloc under the covers.

Shouldn't the allocator be customizable in some way? (Perhaps follow
Andrei's allocator design?)

Regards,
Alex

On Fri, Feb 10, 2012 at 3:32 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
> I'll take a shot at implementing std.typecons.Unique.
> Any opinions or ideas?
>
> My main goals is that it should use malloc under the covers.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

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

2012/2/10 Martin Nowak <dawg at dawgfoto.de>:
> I'll take a shot at implementing std.typecons.Unique.
> Any opinions or ideas?
>
> My main goals is that it should use malloc under the covers.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I think that unique_ptr of the C++ serves as a reference very much on implementing this.

Unique is intended that the only instance owns a right to release a resource.
This is effective in restraining that GC releases a resource.
To this end, it is necessary for the instance that Unique manages to
be isolated from the scan route of the GC. So, I used way to register
the instance that I assigned by malloc a scan root of the GC.

My implementation is here: https://github.com/shoo/voile/blob/master/voile/misc.d#L1048

This implementation is slightly old and is a problem design.
I should not have used alias this for Unique. I think that Kenji's
ProxyOf is very effective as the substitute. (
https://github.com/D-Programming-Language/phobos/pull/300 )
I'll improve this sometime soon.

2012/2/10 Martin Nowak <dawg at dawgfoto.de>:
> I'll take a shot at implementing std.typecons.Unique.
> Any opinions or ideas?
>
> My main goals is that it should use malloc under the covers.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

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.

> 2012/2/10 Martin Nowak <dawg at dawgfoto.de>:
>> I'll take a shot at implementing std.typecons.Unique.
>> Any opinions or ideas?
>>
>> My main goals is that it should use malloc under the covers.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

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

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.

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.