Coming back, Unique, opDot and whatever else

[Stanislav Blinov]

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