Coming back, Unique, opDot and whatever else

[Stanislav Blinov]

On Friday, 17 January 2014 at 07:34:58 UTC, Jacob Carlborg wrote:

> opDot has been replaced with opDispatch [1] and "alias this" 
> [2].

I know, it was just a shortcut "for now". Although alias this is 
of little help in case of Unique, at least without additional 
"middle man". After all, the whole purpose of Unique is to 
swallow the reference and never let anyone outside the family lay 
hands on it :)

Surely, opDot() is not a panacea either, you can always steal a 
reference by doing auto x = u.opDot().

I was thinking about brewing up a middle man using reflection. A 
hypothetical PublicInterface(T) mixin which could dispatch 
function calls with opDispatch and public data access with its 
own properties. But that's limiting. I haven't completely thought 
it over yet, and am open for suggestions :)

> Why can't @safe be used, can you use @trusted instead?

As far as I understand it, it can. I mean, I don't see where I 
would violate any of the rules attached to @safe. The only danger 
zone is dereference, and that's protected by throwing. But I 
commented it out because I started having doubts: in my unittests 
(they're in separate module so they have the same access as the 
user code would) I have three simple classes that don't have any 
@safe attributes on their functions. Unique would fail to compile 
with those ("failed semantic analysis"). So it would seem it's 
rather restrictive. I don't mind imposing correctness, but how 
far should it go?

> You should probably use template constraints for "createUnique" 
> as well.

In my opinion, static assert allows for nicer error messages.

> As for coding style, especially if you're aiming for including 
> in Phobos:

If only in some distant future :)

> * Function names never start with underscore and always starts 
> with a lowercase letter

Oh, yeah, those. Those would go away outside, as private members 
of a module :)

But that brings another point. No matter how opDot() could be 
replaced (be it alias this or that potential mixin I mentioned), 
Unique does have a public method of its own (release()). How 
would one resolve collisions in this case? I mean, if a wrapped 
object has its own release() method? In the opDot() case, one can 
write x.opDot().release(). Could similar be done with alias this?

> * I would prefer the same for instance variables as well, but I 
> know there are several cases in Phobos where instance variables 
> starts with an underscore

Got it, thanks!