On Saturday, 18 January 2014 at 11:00:44 UTC, Jacob Carlborg wrote:
>> Ahem. Wasn't it what I said? :)
>
> I don't know, perhaps I missed that :)

Perhaps :o)

>> Of course I did try. My concern is that
>> it would stop accepting arbitrary user types. Most times this would be a
>> good thing. But not always. Hence I'm hesitating :)
>
> Right, but the opposite could be said as well. If it's not marked with @safe no other functions marked with @safe can call the function. But any non-safe function can call @safe functions.

I think I found out where I was going wrong with @safe. I was misinterpreting error messages. After rereading the docs and some older posts on these newsgroups it all clicked into place. In my current iteration all functions are @safe. Makes sense, since all they do is moving/nullifying one poor pointer around :) Exceptions are clearUnique(), because it calls destroy() (which is @system), and createUnique() itself (so that it could call constructors). Both are @trusted.

But it would seem all of this would be irrelevant soon, since there's ongoing work on allowing automagic inference of attributes for methods of template classes/structs.

> Alternatively, as you wrote in a comment, use free functions. Since they would be declared in the same module they would have access to the private data. Hmm, but the compiler prefers opDispatch before UFCS.

That's the approach I took. I've moved both _Transfer and _Clear into module scope and renamed them. And indeed, the compiler prefers opDispatch(). But not if I call them like .clearUnique(this) :)

So the only public method collision that's possible right now is release(), but there's nothing that can be done about it. If I move it outside too, compiler would want to call wrong method is encapsulated type declares its own release().

> Does opDot even work?

Yes, but I ditched it too already :)

I've also added some more operations, like casts for class types, null assignment, and an operator to squeeze the value from the Unique back into normal type land (discarding "uniqueness", of course). But I feel kind of uncomfortable having it like an operator, even though this looks sort of sensible:

Widget a;
Unique!Widget u;
//...
a << u; // after that a holds the value and u is null

Maybe this would be better off as another method. What do you think?

That's how it all looks currently: http://codepad.org/21vejNKK

On 2014-01-18 13:07, Stanislav Blinov wrote:

> That's the approach I took. I've moved both _Transfer and _Clear into
> module scope and renamed them. And indeed, the compiler prefers
> opDispatch(). But not if I call them like .clearUnique(this) :)

Right, I was mostly thinking of public methods, but those are private.

> So the only public method collision that's possible right now is
> release(), but there's nothing that can be done about it. If I move it
> outside too, compiler would want to call wrong method is encapsulated
> type declares its own release().
>
>> Does opDot even work?
>
> Yes, but I ditched it too already :)
>
> I've also added some more operations, like casts for class types, null
> assignment, and an operator to squeeze the value from the Unique back
> into normal type land (discarding "uniqueness", of course). But I feel
> kind of uncomfortable having it like an operator, even though this looks
> sort of sensible:
>
> Widget a;
> Unique!Widget u;
> //...
> a << u; // after that a holds the value and u is null
>
> Maybe this would be better off as another method. What do you think?

Absolutely. We don't want operator overload abuse.

> That's how it all looks currently: http://codepad.org/21vejNKK

Now with tests :)

-- 
/Jacob Carlborg

opDispatch works do you can just type object.release

On Sunday, 19 January 2014 at 22:25:08 UTC, Rory McGuire wrote:
> opDispatch works do you can just type object.release

This will call Unique's release(). To get to wrapped object's release(), you need object.opDispatch("release")().