On Friday, 17 January 2014 at 07:34:58 UTC, Jacob Carlborg wrote:
opDot has been replaced with opDispatch  and "alias this"
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"
In my opinion, static assert allows for nicer error messages.
As for coding style, especially if you're aiming for including
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!